dynamic type checking - a pauline conversion?
Robert C. Martin
> To: Uncle Bob.
>
> My impression is that your opinion on the relative benefits of dynamic
> and static type checking, has changed over the years.
>
> Have you written about the circumstances which led you to think
> differently?
Yes, I wrote this up in a blog on artima:
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
I've been a statically typed bigot for quite a few years. I learned my
lesson the hard way while using C. Too many systems crashed in the
field due to silly typing errors. When C++ came out, I was an avid
adopter, and rabid enforcer of strong typing. I scoffed at the
smalltalkers who whined about the loss of flexibility. Safety, after
all, was far more important than flexibility -- and besides, we can
keep our software flexible AND statically typed, if we just follow
good dependency management principles.
Four years ago I got involved with Extreme Programming. I liked the
pragmatic emphasis it placed upon developing software. I also liked
the emphasis it put on testing. Since then I have become test
infected. I can no longer conceive of writing software without using
test driven development. I can't imagine not having a comprehensive
suite of unit tests to back up my development.
About two years ago I noticed something. I was depending less and less
on the type system for safety. My unit tests were preventing me from
making type errors. The more I depended upon the unit tests, the less
I depended upon the type safety of Java or C++ (my languages of
choice).
I thought an experiment was in order. So I tried writing some
applications in Python, and then Ruby (well known dynamically typed
languages). I was not entirely surprised when I found that type issues
simply never arose. My unit tests kept my code on the straight and
narrow. I simply didn't need the static type checking that I had
depended upon for so many years.
I also realized that the flexibility of dynamically typed languages
makes writing code significantly easier. Modules are easier to write,
and easier to change. There are no build time issues at all. Life in a
dynamically typed world is fundamentally simpler.
Now I am back programming in Java because the projects I'm working on
call for it. But I can't deny that I feel the tug of the dynamically
typed languages. I wish I was programming in Ruby or Python, or even
Smalltalk.
Does anybody else feel like this? As more and more people adopt test
driven development (something I consider to be inevitable) will they
feel the same way I do. Will we all be programming in a dynamically
typed language in 2010?
JXStern
<uncl...@objectmentor.com> wrote:
>About two years ago I noticed something. I was depending less and less
>on the type system for safety. My unit tests were preventing me from
>making type errors. The more I depended upon the unit tests, the less
>I depended upon the type safety of Java or C++ (my languages of
>choice).
Ha!
Try unit-testing Petzold-style message-loop Windows 2.x programs
(circa 1987), where an hdc/hwnd error hangs the machine.
>Does anybody else feel like this? As more and more people adopt test
>driven development (something I consider to be inevitable) will they
>feel the same way I do. Will we all be programming in a dynamically
>typed language in 2010?
You say the issue never even comes up when you use Python and Ruby, so
what does TDD have to do with it?
Soft/dynamic/variable-typed languages have their benefits, one may
even say they are sort of the same benefits that XP advocates seem to
like - freedom. That is not to say *untyped*, but modern languages
have all sorts of enums and objects and whatnot that carry constraints
and type info at the syntactic level. Given that, the need for
compile-time checking is somewhat more redundant than in early days.
Also, given more robust OS support for error-handling!
Joshua Stern
Daniel T.
> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?
I love creating systems using dynamic typed languages, I hate having to
decipher a system that was built using a dynamic typed language. Take a
large scale program written in a dynamic typed language and see how long
it takes to make a list of all the types that can be used in a
particular variable, then do the same with a static typed language. The
former job can be a day long undertaking at times, the latter is so
simple, there are tools that can do it automatically...
Maybe it's stupid of me to want to know this information in the first
place...
[client]<>--->[AbstractConcept]
A
|
+--+--+
| |
[A] [B]
In C++ the above might look something like:
class AbstractConcept { };
class Client {
AbstractConcept* as;
};
class A: public AbstractConcept { };
class B: public AbstractConcept { };
In Python:
class Client:
def __init__(self):
self.abstractConcept = #whatever
class A:
pass
class B:
pass
Notice that in the Python code, the abstract concept is almost
completely absent (it's demoted to the name of the object.) And the only
way we can determine the properties of the abstract concept is to
examine all uses of the object in Client (and all clients that Client
might expose its variable to,) there is no central repository even
outlining the methods this particular abstract concept must be able to
support.
All three classes (Client, A and B) depend on this abstract concept, but
in dynamic typed languages, the concept exists solely in the minds of
the programmers. There is no embodiment of this concept in the code
itself.
To me the type safety exists simply because more information is being
fed to the compiler, information that the compiler can use to make
certain assumptions. Information that fellow programmers can use to
understand the concepts being used by the designers of the system.
Or to put it another way, I often write OO examples in a static typed
language (rather than a dynamic typed one) simply because more
information is exposed in the example when using such languages.
Universe
news:cmos401b4aa3lu33q...@4ax.com...
Static typing would tend to enforce a rational object model, more oriented
toward initial up-front analysis, it seems.
I like Dynamic OOPLs, however it appears XP'ers use them to facilitate
a little hack here, another hack there, etc and so forth.
Elliott
Ron Jeffries
>Static typing would tend to enforce a rational object model, more oriented
>toward initial up-front analysis, it seems.
Partly yes, partly no. Static typing constrains, often severely, what one can
do, or the difficulty of doing it. This places a higher value on up-front
consideration, to avoid dead ends.
However, because of the artificial constraints often imposed, static typing can
also force one to a design which is less natural, less rational, than one would
use in a more dynamic language.
In all, I prefer the dynamic side. Although I came to dynamic typing after
static, and had fears that the freedom would lead to bad designs and unreliable
code, that turned out not to be the case. The result, for me, was simpler
programs, better designs, higher productivity.
>
>I like Dynamic OOPLs, however it appears XP'ers use them to facilitate
>a little hack here, another hack there, etc and so forth.
I always forget the technical terms. Is this slander, libel, or just lies?
Regards,
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Daniel T.
> On Tue, 9 Mar 2004 23:56:25 -0500, "Universe" <univ...@tAkEcovadOuT.net>
> wrote:
>
> >Static typing would tend to enforce a rational object model, more oriented
> >toward initial up-front analysis, it seems.
>
> Partly yes, partly no. Static typing constrains, often severely, what one can
> do, or the difficulty of doing it. This places a higher value on up-front
> consideration, to avoid dead ends.
>
> However, because of the artificial constraints often imposed, static typing
> can
> also force one to a design which is less natural, less rational, than one
> would
> use in a more dynamic language.
What constraints are you talking about? I know of no constraints imposed
by static typed languages that don't also exist (implicitly) in dyanamic
typed languages.
Peter Hermann
> Does anybody else feel like this?
no
> Will we all be programming in a dynamically
> typed language in 2010?
Robert,
I know you since more than one decade as a strongheaded Ada ignorer.
Nevertheless I read your whole contribution and again shook my head.
All your needs are fulfilled by Ada, hands down.
Well, then, for the others:
http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html
--
--Peter Hermann(49)0711-685-3611 fax3758 ica...@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)
Ilja Preuß
> What constraints are you talking about? I know of no constraints
> imposed
> by static typed languages that don't also exist (implicitly) in
> dyanamic typed languages.
We do have a utility method which does the following:
if (closable != null) closable.close();
In Java, you cannot write this method so that it supports InputStream,
OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
etc. - just because there is no Closable interface (other than using
reflection, which is basically emulating the feature of dynamic type
checking).
Take care, Ilja
Ilja Preuß
> Robert,
> I know you since more than one decade as a strongheaded Ada ignorer.
> Nevertheless I read your whole contribution and again shook my head.
> All your needs are fulfilled by Ada, hands down.
Interesting - how does Ada solve the Closable problem I explained in my
other post in this thread?
Curious, Ilja
James A. Robertson
wrote:
>On Tue, 09 Mar 2004 18:40:19 -0600, Robert C. Martin
><uncl...@objectmentor.com> wrote:
>>About two years ago I noticed something. I was depending less and less
>>on the type system for safety. My unit tests were preventing me from
>>making type errors. The more I depended upon the unit tests, the less
>>I depended upon the type safety of Java or C++ (my languages of
>>choice).
>
>Ha!
>
>Try unit-testing Petzold-style message-loop Windows 2.x programs
>(circa 1987), where an hdc/hwnd error hangs the machine.
Which would be relevant to anything today how?
>
>>Does anybody else feel like this? As more and more people adopt test
>>driven development (something I consider to be inevitable) will they
>>feel the same way I do. Will we all be programming in a dynamically
>>typed language in 2010?
>
>You say the issue never even comes up when you use Python and Ruby, so
>what does TDD have to do with it?
>
>Soft/dynamic/variable-typed languages have their benefits, one may
>even say they are sort of the same benefits that XP advocates seem to
>like - freedom. That is not to say *untyped*, but modern languages
>have all sorts of enums and objects and whatnot that carry constraints
>and type info at the syntactic level. Given that, the need for
>compile-time checking is somewhat more redundant than in early days.
>Also, given more robust OS support for error-handling!
>
>Joshua Stern
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
James A. Robertson
<postm...@eathlink.net> wrote:
>Robert C. Martin <uncl...@objectmentor.com> wrote:
>
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>I love creating systems using dynamic typed languages, I hate having to
>decipher a system that was built using a dynamic typed language. Take a
>large scale program written in a dynamic typed language and see how long
>it takes to make a list of all the types that can be used in a
>particular variable, then do the same with a static typed language. The
>former job can be a day long undertaking at times, the latter is so
>simple, there are tools that can do it automatically...
>
I think that runs pretty much the opposite of my experience. I spent
many years doing C, and I've spent many years doing Smalltalk. I have
many recollections of being tossed in front of unfamiliar C code, and
being finding it extremely hard to follow. Oddly enough, having the
word 'int' in front of various variables didn't help a lot.
Smalltalk, on the other hand, is much, much easier to deal with that
way. I've been in front of many unfamiliar systems as a consultant,
and been able to figure out what they were up to pretty quickly.
IMHO, the presence of typing information neither helps nor hinders in
following unfamiliar code.
>Maybe it's stupid of me to want to know this information in the first
>place...
>
Maybe that information is just of no inherent value....
<Talk Small and Carry a Big Class Library>
Ilja Preuß
>>> Does anybody else feel like this? As more and more people adopt test
>>> driven development (something I consider to be inevitable) will they
>>> feel the same way I do. Will we all be programming in a dynamically
>>> typed language in 2010?
>>
>> You say the issue never even comes up when you use Python and Ruby,
>> so what does TDD have to do with it?
"My unit tests kept my code on the straight and narrow", I'd guess.
Take care, Ilja
JXStern
<jar...@gosmalltalk.com> wrote:
>>Try unit-testing Petzold-style message-loop Windows 2.x programs
>>(circa 1987), where an hdc/hwnd error hangs the machine.
>
>Which would be relevant to anything today how?
It's a data point from a time when programming was done without types,
and people suffered from it. It seems to confirm RCM's initial
thought that there's a problem in there someplace, but suggests that
there's more to fixing it than doing TDD. It suggests that strong
typing available in C++ might be advisable, might prevent whole
classes of problems, in that old environment and in newer ones.
Have a nice day.
J.
thoff
Robert C. Martin wrote:
> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?
You are saying a dynamically typed language is the best choice
for all circumstances? That i don't agree with.
Your choice is based on the assumption that people will write
unit tests and maintain them. That is simply not a justifiable
assumption in 95% of the people i have ever worked with. Even
those that do use TDD i have found the quality of the effort is
still very developer specific.
Given my assumption then i must use judgement as to what is
important in what situation. I know, we rather replace judgement
with simplistic rules, but i still think judgement is what
professionals with experience can bring to the game.
I use perl and no unit testing for even
very complicated web sites and that works well enough 99% of
the time because i find bugs are rare regardless of the methodology.
Few people work on the system. No problem. Unit testing in this
case is an uncessary burden.
On another system that is a C++ based in a very complex embedded
environment with a 100 developers of different abilities spaced
all over the country. A single mistake can cost millions. In this
environment i very glad for static type checking because i *know*
i can not rely on people writing and updating unit tests. The overhead
of defining abstract interfaces is very small in this scenario
given the payoff.
I find absolute rules, though they make good grist for discussion,
are not that useful because you must find a solution that meets
your requirements and your problem space. Assuming into existence
a group of engineers who write high quality unit tests and update
them 100% of the time is a very hard precondition.
Shayne Wissler
"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
news:cmos401b4aa3lu33q...@4ax.com...
> I've been a statically typed bigot for quite a few years. ...
> When C++ came out, I was an avid
> adopter, and rabid enforcer of strong typing.
...
> Four years ago I got involved with Extreme Programming.
...
> Since then I have become test
> infected. I can no longer conceive of writing software without using
> test driven development.
...
> Life in a dynamically typed world is fundamentally simpler.
...
> Does anybody else feel like this? As more and more people adopt test
> driven development (something I consider to be inevitable) will they
> feel the same way I do. Will we all be programming in a dynamically
> typed language in 2010?
No, I don't, and Bob, do you see the pattern the above? You seem to swing
from one Extreme to another. How about some moderation?
I think static typing has important uses. I also think dynamic techniques
have important uses. My ideal language has both features. Which lets me
decide what is appropriate based on the situation at hand (but in general I
would use static typing more often--there's no point in writing extra tests
for something that can be tested by the compiler, and a statically typed
program is more easily understood).
Shayne Wissler
Tsolak Petrosian
dynamic languages since "object" in those languages cannot dynamically
change its type.
Tsolak Petrosian
Ilja Preuß
As the subject of this thread indicates, it's about dynamic *type checking*.
Ruby, Python and Smalltalk are dynamically typed languages (which means that
the type of an object is checked at runtime instead of compile time, as far
as I know).
Take care, Ilja
Thomas Gagné
types. Of course, using it is considered a design problem and strongly
discouraged, I think. I've had no use for it (yet).
Tsolak Petrosian wrote:
--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org
Dave Harris
> >>Try unit-testing Petzold-style message-loop Windows 2.x programs
> >>(circa 1987), where an hdc/hwnd error hangs the machine.
> >
> >Which would be relevant to anything today how?
>
> It's a data point from a time when programming was done without types,
> and people suffered from it.
No-one is advocating programming without types. RCM is talking about
checking the types at run-time. If that were done by Windows 2.x, mixing
an HDC with an HWND would give a well-defined error rather than a machine
hang.
The Petzold-style message-loop may be hard to unit test; I don't know. If
it is, I'd say that was an argument for not using Petzold style.
-- Dave Harris, Nottingham, UK
JXStern
bran...@cix.co.uk (Dave Harris) wrote:
>> >>Try unit-testing Petzold-style message-loop Windows 2.x programs
>> >>(circa 1987), where an hdc/hwnd error hangs the machine.
>> >
>> >Which would be relevant to anything today how?
>>
>> It's a data point from a time when programming was done without types,
>> and people suffered from it.
>
>No-one is advocating programming without types. RCM is talking about
>checking the types at run-time. If that were done by Windows 2.x, mixing
>an HDC with an HWND would give a well-defined error rather than a machine
>hang.
And I'm agreeing with RCM. If you put a typed value into a variant,
it's still checkable. It's all good.
But you couldn't do any of that, back in the day, and without it, TDD
wouldn't help, at least not nearly as much as static typing.
>The Petzold-style message-loop may be hard to unit test; I don't know. If
>it is, I'd say that was an argument for not using Petzold style.
Anything that locks up and costs you five minutes to reboot and
reestablish when you hit a bug is a major pain (and doing realtime
message parsing, you can't step through it effectively either).
Only the guys who write runtime libraries even know what a message
loop is anymore, VC/MFC and VB obsoleted Petzold-style programming by
about 1991 and nobody misses it in the least. How often do you even
have to make a raw API call anymore?
J.
Universe
"Dave Harris" <bran...@cix.co.uk> wrote in message
news:memo.20040310185240.456A@brangdon.m...
A post<=>dispatch message loop is an integral part of the way the Windows OS
operates. I.E. the Petzold's message loop simply exposes what is happening
in the Windows kernel. The way the code for various Windows boxes
communicates is by posting to Windows and Windows then dispatches the
intended recipient code. Both the post and dispatch occur in a loop. This
happens even today with WinXP. The loop however has been "subsumed" within
the MFC, .NET, etc API's.
Elliott
--
Several powerful techniques are available to control the flow of information
to viewer,
including progressive disclosure, detail hiding, and layering and
separation.
As Massironi notes in his discussion about graphic images, "useful
drawings are not
exhaustive; they are selective".
Ron Jeffries
>> However, because of the artificial constraints often imposed, static typing
>> can
>> also force one to a design which is less natural, less rational, than one
>> would
>> use in a more dynamic language.
>
>What constraints are you talking about? I know of no constraints imposed
>by static typed languages that don't also exist (implicitly) in dyanamic
>typed languages.
I'm thinking largely of the constraints around needing to declare everything in
advance, which leads to tons of declared interfaces, and objects that want to
inherit from lots of them. Offhand, I can't think of anything I couldn't
program, but I find that the need to do all that declaration makes some
solutions harder to get to in practice, even though they are technically
possible.
Does that help to clarify? If not, inquire further ...
Ron Jeffries
This reminds me of a related topic which isn't a property, strictly speaking, of
static vs dynamic, but that seems to come along with dynamic languages and much
more rarely with static. In the D languages I most like to use, everything
really is an object, and therefore everything is nullable. In the static
languages, some primitive types are not nullable.
you can always program around that ... but it's not what I'd call elegant.
Isaac Gouy
> Take a large scale program written in a dynamic typed language and see how
> long it takes to make a list of all the types that can be used in a
> particular variable, then do the same with a static typed language. The
> former job can be a day long undertaking at times, the latter is so
> simple, there are tools that can do it automatically...
> Maybe it's stupid of me to want to know this information in the first
> place...
That would depend on why you wanted to know ;-)
-snip_
> Notice that in the Python code, the abstract concept is almost
> completely absent
Hmmm is it impossible to define abstract classes in Python?
Smalltalk IDEs *generate* a verbose template for class definition; the
different class definitions shown in the IDE would be something like
this:
Smalltalk defineClass: #Client
superclass: #{Core.Object}
instanceVariableNames: 'abstractConcept'
Smalltalk defineClass: #AbstractConcept
superclass: #{Core.Object}
Smalltalk defineClass: #A
superclass: #{Smalltalk.AbstractConcept}
Smalltalk defineClass: #B
superclass: #{Smalltalk.AbstractConcept}
> All three classes (Client, A and B) depend on this abstract concept, but
> in dynamic typed languages, the concept exists solely in the minds of
> the programmers.
As we've seen we can also use abstract classes in a dynamically
checked language.
Daniel Parker
news:c2n6hj$ov3$1...@stu1id2.ip.tesion.net...
problem do you solve when you have a generic method call close on an
arbitary object? Is this just to save yourself from writing a few lines of
code, or do you find yourself dealing with broad classes of system resources
in a generic manner? Would you handle errors and exceptions from calling
close on a file resource and a database resource in the same way?
Regards,
Daniel Parker
Isaac Gouy
> We do have a utility method which does the following:
>
> if (closable != null) closable.close();
>
> In Java, you cannot write this method so that it supports InputStream,
> OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> etc. - just because there is no Closable interface (other than using
> reflection, which is basically emulating the feature of dynamic type
> checking).
So there is no existing interface that includes the method 'close' and
is implemented by all of the types we wish to assign to the variable
'closeable'. The general solution is to define a new interface
ICloseable and redefine all of the types to implement ICloseable.
In Java (without AspectJ) the only way we can do that is by editing
the source code for all the class definitions (which wouldn't be a
great approach even if we had the source code).
In Nice, a statically checked language, (and other multimethod
languages) we can retroactively add a new interface to class
definitions. Here's one example:
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodExample
Daniel T.
But there is absolutely no requirement that a class inherit from
AbstractConcept in order to be used, or useful in the variable
'abstractConcept'. The AbstractConcept class literally does nothing in
the SmallTalk code, the only possible use of the class is a repository
for any shared implementation of the various subclasses, which could as
easily be placed in a delegate, or duplicated in the clients. Changes
can be made to the class "Client" that assume a change in the
AbstractConcept interface, and as long as classes A and B are modified
to suit, no change need be made to AbstractConcept itself, thus allowing
a drift between the class AbstractConcept, and the actual concept it is
supposed to represent.
All of this means that I cannot easily tell if an object of a particular
class is useful in the variable 'abstractConcept' unless I make a
detailed study of what messages are sent to 'abstractConcept'.
Please don't take this as a slam against dynamic typed languages, as I
said I like using them. I think they help a programer generate systems
faster than in static typed languages.
Daniel T.
> Daniel T. wrote:
>
> > What constraints are you talking about? I know of no constraints
> > imposed
> > by static typed languages that don't also exist (implicitly) in
> > dyanamic typed languages.
>
> We do have a utility method which does the following:
>
> if (closable != null) closable.close();
Call me ignorant, but I'm not sure who "we" are in the above. The code
looks more like Java or C++ than any dynamic language I know of.
> In Java, you cannot write this method so that it supports InputStream,
> OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> etc. - just because there is no Closable interface (other than using
> reflection, which is basically emulating the feature of dynamic type
> checking).
closable.close(); would not work with any class that doesn't have a
"close" method no matter what language you wish to work with. I would be
very wary of just assuming that a method that happens to have the name
I'm calling will arbitrarily do the right thing if the method wasn't
written with the concept I'm using in mind. IE:
interface MyClosable {
public void close();
}
I can reasonably assume that any class that inherits from the above will
work with any class that uses the above interface as a client, simply
because the class designer had to have the forethought to know what
'close' was supposed to do when inheriting from my particular Closable
class. Even if he was using the adaptor pattern to do such a thing:
class FooClosable implements MyClosable {
private Foo itsFoo;
public void close() {
itsFoo.cleanUpData();
}
}
In the above code, the programmer is explicitly stating that some
designer's concept of "cleanUpData" maps directly to my concept of
"close" for all the places where I use my "MyClosable" interface. Note,
it isn't necessarily the case that JoesClosable.close() maps directly to
MyClosable.close(), but if I see an adaptor that maps the two, then I
know that a programmer knew enough about the MyClosable interface and
the JoesClosable interface and was able to determine that they do indeed
map well.
Daniel T.
> "Ilja Preuß" <pre...@disy.net> wrote:
>
> > We do have a utility method which does the following:
> >
> > if (closable != null) closable.close();
> >
> > In Java, you cannot write this method so that it supports InputStream,
> > OutputStream, Reader, Writer, Socket, ResultSet, Statement, Connection
> > etc. - just because there is no Closable interface (other than using
> > reflection, which is basically emulating the feature of dynamic type
> > checking).
>
> So there is no existing interface that includes the method 'close' and
> is implemented by all of the types we wish to assign to the variable
> 'closeable'. The general solution is to define a new interface
> ICloseable and redefine all of the types to implement ICloseable.
>
> In Java (without AspectJ) the only way we can do that is by editing
> the source code for all the class definitions (which wouldn't be a
> great approach even if we had the source code).
Or one could make adaptor classes.
> In Nice, a statically checked language, (and other multimethod
> languages) we can retroactively add a new interface to class
> definitions. Here's one example:
> http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodEx
> ample
Which is effectively the same as making adaptor classes.
Daniel T.
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
> On Wed, 10 Mar 2004 12:53:45 GMT, "Daniel T." <postm...@eathlink.net>
> wrote:
>
> >> However, because of the artificial constraints often imposed, static
> >> typing
> >> can
> >> also force one to a design which is less natural, less rational, than one
> >> would
> >> use in a more dynamic language.
> >
> >What constraints are you talking about? I know of no constraints imposed
> >by static typed languages that don't also exist (implicitly) in dyanamic
> >typed languages.
>
> I'm thinking largely of the constraints around needing to declare everything
> in
> advance, which leads to tons of declared interfaces, and objects that want to
> inherit from lots of them. Offhand, I can't think of anything I couldn't
> program, but I find that the need to do all that declaration makes some
> solutions harder to get to in practice, even though they are technically
> possible.
>
> Does that help to clarify? If not, inquire further ...
I agree, it can be a pain to have to actually write down all the various
interfaces that are running around in your head while coding. Often
times, programmers using static typed languages don't bother and then
curse the language when they can't easily plug in their new class. On
the other hand...
There is real value in the "compilable comment"; code that is ment to
help clarify the design of the system, which the compiler can check.
That's what interfaces are. They put more knowledge of the design *into*
the design, rather than only in the designer's heads.
You see, I believe that all thoses things that need to be "declared in
advance" in a static typed language, also need to be at least conceved
of in advance in a dyanimic typed language, even if they don't need to
be explicitly expressed in the code.
Peter Ammon
Static typing and dynamic typing are not mutually exclusive, and you're
right that statically typed languages are not more limited than
dynamically typed languages.
However, when the generated code depends on the static type information,
suddenly you are limited. The features I enjoy most in dynamically
typed languages, such as the ability to add methods to classes, replace
one class with another, replace one method with another, etc. at runtime
aren't doable in languages that generate code based on static type
information.
--
Pull out a splinter to reply.
Robert C. Martin
<thalesN...@yahoo.com> wrote:
>
>"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
>news:cmos401b4aa3lu33q...@4ax.com...
>
>> I've been a statically typed bigot for quite a few years. ...
>> When C++ came out, I was an avid
>> adopter, and rabid enforcer of strong typing.
>
>...
>
>> Four years ago I got involved with Extreme Programming.
>
>...
>
>> Since then I have become test
>> infected. I can no longer conceive of writing software without using
>> test driven development.
>
>...
>
>> Life in a dynamically typed world is fundamentally simpler.
>
>...
>
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>No, I don't, and Bob, do you see the pattern the above? You seem to swing
>from one Extreme to another. How about some moderation?
(sigh).
Robert C. Martin
>Ron Jeffries <ronje...@REMOVEacm.org> wrote:
>
>> On Tue, 9 Mar 2004 23:56:25 -0500, "Universe" <univ...@tAkEcovadOuT.net>
>> wrote:
>>
>> >Static typing would tend to enforce a rational object model, more oriented
>> >toward initial up-front analysis, it seems.
>>
>> Partly yes, partly no. Static typing constrains, often severely, what one can
>> do, or the difficulty of doing it. This places a higher value on up-front
>> consideration, to avoid dead ends.
>>
>> However, because of the artificial constraints often imposed, static typing
>> can
>> also force one to a design which is less natural, less rational, than one
>> would
>> use in a more dynamic language.
>
>What constraints are you talking about? I know of no constraints imposed
>by static typed languages that don't also exist (implicitly) in dyanamic
>typed languages.
Imagine that you have a derivative that has a method. You are adding
code to that method and decide that you need to throw an exception.
No other implementations of that method in other derivatives throw
exceptions. Hundreds of modules call the function through the base
class interface. Hundreds of other modules use the base class
interface without calling the method.
How many source files need to be changed to accommodate the "throws"
clause? How many modules must be recompiled because of those changes.
How many DLLs or jar files must be redeployed because of those
recompilations?
If the answer to any of those questions is a number larger than one,
then that represents a constraint that a dynamically typed language
doesn't have -- even implicitly. If the build time for the change is
much larger than a second, then that represents a constraint that a
dynamically typed language doesn't have.
Robert C. Martin
>
>
>Robert C. Martin wrote:
>> Does anybody else feel like this? As more and more people adopt test
>> driven development (something I consider to be inevitable) will they
>> feel the same way I do. Will we all be programming in a dynamically
>> typed language in 2010?
>
>You are saying a dynamically typed language is the best choice
>for all circumstances?
No, I was simply asking whether anyone who practices TDD has found
that no longer value static typing as much as they used to.
>Your choice is based on the assumption that people will write
>unit tests and maintain them.
My choice is based on the fact that *I* will write and maintain unit
tests. I wonder if anyone else who will behave the same way, has made
the same decision that I have.
>That is simply not a justifiable
>assumption in 95% of the people i have ever worked with. Even
>those that do use TDD i have found the quality of the effort is
>still very developer specific.
The question is whether it is enough for each of them individually to
make the same decision I did. I'm not asking if this is a good thing
or not. If TDD continues to be practiced more and more, will each
individual relax their reliance on static type checking?
>Given my assumption then i must use judgement as to what is
>important in what situation. I know, we rather replace judgement
>with simplistic rules, but i still think judgement is what
>professionals with experience can bring to the game.
Of course. Indeed, my question is about such a judgement call.
>I use perl and no unit testing for even
>very complicated web sites and that works well enough 99% of
>the time because i find bugs are rare regardless of the methodology.
>Few people work on the system. No problem. Unit testing in this
>case is an uncessary burden.
I, on the other hand, have found that writing unit tests concurrently
with code is less burdensome than not writing them, even in very
simple systems. This is a personal decision that applies to me and
may not apply to everyone.
>On another system that is a C++ based in a very complex embedded
>environment with a 100 developers of different abilities spaced
>all over the country. A single mistake can cost millions. In this
>environment i very glad for static type checking because i *know*
>i can not rely on people writing and updating unit tests. The overhead
>of defining abstract interfaces is very small in this scenario
>given the payoff.
I wonder. Given a team of experienced folks who conscientiously
practice TDD, could they use a dynamically typed language to deliver
the project faster, cheaper, and better? I think it could be.
>I find absolute rules, though they make good grist for discussion,
>are not that useful because you must find a solution that meets
>your requirements and your problem space. Assuming into existence
>a group of engineers who write high quality unit tests and update
>them 100% of the time is a very hard precondition.
200 years ago you'd have had trouble finding doctors who bothered to
wash their hands before surgery. Nowadays you won't find one who
doesn't *diligently* wash his hands. 25 years ago you'd have had
trouble finding a software developer who didn't use goto. Nowadays
they are pretty rare. Practices change, and it doesn't really take
that long for them to change. I think it's possible that in a few
years TDD could be viewed as a standard of professional behavior.
Robert C. Martin
<ica...@sinus.csv.ica.uni-stuttgart.de> wrote:
>Robert,
>I know you since more than one decade as a strongheaded Ada ignorer.
I am certainly an Ada ignorer. The ignorance is not strongheaded
however. I'd like to learn Ada. I've just never had the need.
>Nevertheless I read your whole contribution and again shook my head.
>All your needs are fulfilled by Ada, hands down.
I don't know, but I thought that large Ada systems might have build
times in excess of one second; or that if I change a function
signature in one Ada module I might have to recompile many other
modules -- even those that don't call it. Am I mistaken?
Phlip
> No, I was simply asking whether anyone who practices TDD has found
> that no longer value static typing as much as they used to.
Before TDD, I would refactor by changing a C++ header file, predict that the
compile would dislike the types of each implementation line that needed
attention, then use the "Next Diagnostic" function key to navigate to each
of those lines and fix them.
After TDD, I make small refactors after writing deliberately bad code to
pass a test. The size and scope of any other kind of refactor has gone way
down (but there's still the occassional party). The ability to navigate code
by forcing type errors is not needed, hence not missed.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces
thoff
Robert C. Martin wrote:
> The question is whether it is enough for each of them individually to
> make the same decision I did. I'm not asking if this is a good thing
> or not. If TDD continues to be practiced more and more, will each
> individual relax their reliance on static type checking?
What you would do personally matters for your personal programming.
My focus is always on pretty complex projects. In that context
it is the project and the characteristics of the group and
management that will decide. It can't be an individual choice,
no more than language selection in a project is an individual choice.
> I, on the other hand, have found that writing unit tests concurrently
> with code is less burdensome than not writing them, even in very
> simple systems. This is a personal decision that applies to me and
> may not apply to everyone.
Burdensome is a big word that can mean very different things
to different people. It implies an assessment of tradefoffs
and values. I find it hard to believe you can determine a policy
absolutely for all circumstances.
> I wonder.
I unfortuntately don't have to.
>Given a team of experienced folks who conscientiously
> practice TDD, could they use a dynamically typed language to deliver
> the project faster, cheaper, and better? I think it could be.
A team of experienced people who get to conscientiously do anything
will deliver the project faster, cheaper, and better. I have
seen this many times. When a team consists partly of
unconscientious people or are who are not allowed to act
conscientiously, then it becomes very difficult to succeed
period.
> 200 years ago you'd have had trouble finding doctors who bothered to
> wash their hands before surgery. Nowadays you won't find one who
> doesn't *diligently* wash his hands.
And do you find studies supporting this practice? Interestingly
i recall Dr Dean Edell saying there wasn't.
>25 years ago you'd have had
> trouble finding a software developer who didn't use goto. Nowadays
> they are pretty rare. Practices change, and it doesn't really take
> that long for them to change. I think it's possible that in a few
> years TDD could be viewed as a standard of professional behavior.
Good is standard behaviour yet evil still thrives. One solution
the problem of evil has been fundamentalism.
Tsolak Petrosian
Here is problem with static types:
Lets assume that some method "m" which as parameter needs an object
with both types of T1 and T2 which dont share any commonality (like be
Displayable and Persistable).
How do you define "m"?
The only solution is to define it as m(Object o).
Tsolak Petrosian
Ilja Preuß
> In Nice, a statically checked language, (and other multimethod
> languages) we can retroactively add a new interface to class
> definitions. Here's one example:
>
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/AspectOrientedMultiMethodExample
I fear I don't understand that example. Where in that code is a new
interface retroactively added to a class definition?
Thanks, Ilja
Ilja Preuß
> "Ilja Preuß" <pre...@disy.net> wrote:
>> We do have a utility method which does the following:
>>
>> if (closable != null) closable.close();
>
> Call me ignorant, but I'm not sure who "we" are in the above. The code
> looks more like Java or C++ than any dynamic language I know of.
Sorry, we means "the team I am working with at work". And it is Java, so we
actually face the problem that conceptually it is one method, but we need to
redefine it for any base type we want to use it for.
>> In Java, you cannot write this method so that it supports
>> InputStream, OutputStream, Reader, Writer, Socket, ResultSet,
>> Statement, Connection etc. - just because there is no Closable
>> interface (other than using reflection, which is basically emulating
>> the feature of dynamic type checking).
>
> closable.close(); would not work with any class that doesn't have a
> "close" method no matter what language you wish to work with.
Correct. I can't remember ever having tried to use the method with an object
not having a close method, though. The typical use is
InputStream in = null;
try {
...
}
finally {
StreamUtilities.close(in);
}
> I would
> be very wary of just assuming that a method that happens to have the
> name I'm calling will arbitrarily do the right thing if the method
> wasn't written with the concept I'm using in mind.
The purpose of the method is to close a non-null object, whatever that means
for that object. I don't see how that could go wrong with any implementation
of close().
> IE:
>
> interface MyClosable {
> public void close();
> }
>
> I can reasonably assume that any class that inherits from the above
> will work with any class that uses the above interface as a client,
> simply because the class designer had to have the forethought to know
> what 'close' was supposed to do when inheriting from my particular
> Closable class.
How do you know that??? All that interface is saying is that the object has
a close method. It doesn't seem to imply anything about what close is meant
to do. Anyway, for my purpose, *any* implementation of close would suffice.
> Even if he was using the adaptor pattern to do such a
> thing:
>
> class FooClosable implements MyClosable {
> private Foo itsFoo;
> public void close() {
> itsFoo.cleanUpData();
> }
> }
>
> In the above code, the programmer is explicitly stating that some
> designer's concept of "cleanUpData" maps directly to my concept of
> "close" for all the places where I use my "MyClosable" interface.
> Note, it isn't necessarily the case that JoesClosable.close() maps
> directly to MyClosable.close(), but if I see an adaptor that maps the
> two, then I know that a programmer knew enough about the MyClosable
> interface and the JoesClosable interface and was able to determine
> that they do indeed map well.
Yes, ok.
But for my purpose it doesn't work, because you can't delegate to null. So
you had to have a check for null in every adapter, which basically makes it
a useless concept in this case, unless I am missing something... :(
Take care, Ilja
Peter Hermann
> I don't know, but I thought that large Ada systems might have build
> times in excess of one second; or that if I change a function
> signature in one Ada module I might have to recompile many other
> modules -- even those that don't call it. Am I mistaken?
These problems existed indeed 20 years ago for large systems.
Today we have clever compilers with clever library concepts
which compile the minimum amount of code but not fewer,
since respecting interdependencies is the real strength of Ada.
--
--Peter Hermann(49)0711-685-3611 fax3758 ica...@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)
Ilja Preuß
I do have a concept of "close this object if it isn't null" which is needed
in many places. As I don't like duplication, I want to put this concept in
exactly one place. In Java, I haven't yet found a way to do that.
Did I make myself more clear?
Take care, Ilja
Dmitry A. Kazakov
You have to recompile the modules depending on the module which
interface contains the signature. If that modules do not call the
function, then the design with respect to how decomposition into
modules was made, is not good, provided that the function has to
undergo permanent signature changes (?) being simultaneously a part of
a module interface! Altogether this example is quite abstract. In
practice, due to strict checks imposed by the language, you will
probably unable to get your module interface compiled, if it contains
a "crazy" function falling out of design. Once you get the interface
right, you will unlikely need to change it ten times per day using it
in hundreds of other modules at the same time. When still the
compilation time became an issue, one should better scrap the whole
project.
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
Dmitry A. Kazakov
wrote:
>Daniel Parker wrote:
package Closable_Things is
type Closable is abstract tagged private;
procedure Close (Object : in out Closable'Class);
-- Called to close an object of any type
procedure Do_Close (Object : in out Closable) is abstract;
-- Implements closing, to be overriden in children
private
type Closable is abstract tagged record
Is_Null : Boolean := True;
end Closable;
end Closable_Things;
package body Closable_Things is
procedure Close (Object : in out Closable'Class) is
begin
if not Object.Is_Null then
Do_Close (Object);
Object.Is_Null := True;
end if;
end Close;
end Closable_Things;
I doubt if that difficult to do in either Java or C++.
Paul Campbell
"Ilja Preuß" <pre...@disy.net> wrote in message news:c2pbol$5cs$1...@stu1id2.ip.tesion.net...
> > I would
> > be very wary of just assuming that a method that happens to have the
> > name I'm calling will arbitrarily do the right thing if the method
> > wasn't written with the concept I'm using in mind.
>
> The purpose of the method is to close a non-null object, whatever that means
> for that object.
> I don't see how that could go wrong with any implementation
> of close().
Your assuming that "close" is always the last thing you want to do with an object, that
may not be the case e.g.
Class RelayController {
void open() ..
void close() ...
}
Paul C.
Paul Campbell
"Robert C. Martin" <uncl...@objectmentor.com> wrote in message news:u7pu40lee08i8d7j6...@4ax.com...
> >What constraints are you talking about? I know of no constraints imposed
> >by static typed languages that don't also exist (implicitly) in dyanamic
> >typed languages.
>
> Imagine that you have a derivative that has a method. You are adding
> code to that method and decide that you need to throw an exception.
> No other implementations of that method in other derivatives throw
> exceptions.
Well thats one hell on an LSP violation - as I'm sure you know :-).
Paul C.
Paul Campbell
"Tsolak Petrosian" <tso...@yahoo.com> wrote in message news:a052897d.04031...@posting.google.com...
> Here is problem with static types:
>
> Lets assume that some method "m" which as parameter needs an object
> with both types of T1 and T2 which dont share any commonality (like be
> Displayable and Persistable).
> How do you define "m"?
> The only solution is to define it as m(Object o).
If they dont share any commonality then then surely there is *nothing* you
can usefully do with such an object other than an explicity dispatch using
an if statement to test its type.
Paul C.
Roger Racine
Rational had an Ada compiler that did not recompile modules that did
not truly need the modifications. I don't know if it still exists (I
haven't been able to use their compilers for a while), but there is
nothing in the language that prohibits compilers from this. When I
asked one vendor why they didn't support that type of feature they
said that compilation times were so fast it wasn't necessary. I
disagree with that vendor's position.
So the answer to your question is that you are exactly correct: you
-might- "have to recompile many other modules -- even those that don't
call it." Then again, you might not.
Roger Racine
Ilja Preuß
>> I don't see how that could go wrong with any implementation
>> of close().
>
> Your assuming that "close" is always the last thing you want to do
> with an object, that may not be the case e.g.
I am not. The only responsibility of the method is to close the object, if
it isn't null. You can use the method where and when you want.
To reiterate, all the method does is
public static void close(SomeType closable) {
if (closable != null) {
closable.close();
}
}
Take care, Ilja
Ilja Preuß
> package Closable_Things is
> type Closable is abstract tagged private;
> procedure Close (Object : in out Closable'Class);
> -- Called to close an object of any type
> procedure Do_Close (Object : in out Closable) is abstract;
> -- Implements closing, to be overriden in children
> private
> type Closable is abstract tagged record
> Is_Null : Boolean := True;
> end Closable;
> end Closable_Things;
>
> package body Closable_Things is
> procedure Close (Object : in out Closable'Class) is
> begin
> if not Object.Is_Null then
> Do_Close (Object);
> Object.Is_Null := True;
> end if;
> end Close;
> end Closable_Things;
>
> I doubt if that difficult to do in either Java or C++.
Well, I surely don't know how to translate it to Java...
Take care, Ilja
jas
Tsolak Petrosian wrote:
> Correct me if I am wrong.
Ok.
> But Ruby, Python and Smalltalk are not truly dynamic languages since
> "object" in those languages cannot dynamically change its type.
Smalltalk is usually considered both strongly typed and dynamically typed.
Strongly - because the sender of a message cannot escape the constraints
imposed by the receiver's type (there is no ability to
re-cast a reference).
Dynamic - because from the sender's point of view, the type of the
receiver is
not bound at compile time; binding is delayed until
runtime - i.e. until
the message is actually sent. The receiver may or may not
change it's
type during execution - the sender does not know, thus the
compiler
cannot generate code which would rely on a statically
determined type.
(Both C++ and Java are statically typed. And weakly typed.)
The primary importance of dynamic binding has to do with parameters -
parameters are not statically annotated with type information.
Hence, any object can be sent as a parameter.
This *seems* to be a reduction in safety.
If you are a C++ programmer, you are used to an illusion.
If you are a Java programmer who would specify the class
of a parameter, you are used to the same illusion.
But if you would *always* specify an interface,
rather than a class, AND you *always* specify
an interface which is minimal, then yes, Smalltalk
does reduce safety *for you*, a little bit.
(We have other tools which compensate for the loss).
Objects can also dynamically change type in at least two ways:
* self changeClassToThatOf: thisOtherObject.
* self become: someOtherObject.
The former changes just the object's class, and is only valid
when the two objects are the same "shape" (meaning instance
variables defined for the two objects are the 'same' in both
number and kind).
The latter causes all references to 'self' (across the entire system)
to be replaced by a reference to the specified object (of any type).
{Hence said change may or may not result in a type change.}
These are quite powerful, hence useful.
And like nitro glycerine, they really shouldn't be tossed about
willy nilly, for similar reasons.
-cstb
Dmitry A. Kazakov
wrote:
>Dmitry A. Kazakov wrote:
Forget Java, (:-)) Ada compilers translate directly into Java byte
code. For example JGNAT (free), Aonix ObjectAda (commercial).
Paul Campbell
"Ilja Preuß" <pre...@disy.net> wrote in message news:c2poni$vo1$1...@stu1id2.ip.tesion.net...
Any void return method by causes no state change is by definition
redundent. Therefore you must be making assumptions about what
it will do otherwise there is simply no point in calling it at all.
Let me put this another way: what will *not* happen if you dont
call this method that will adversely impact the functioning of the
system ?.
Paul C.
Shayne Wissler
> Here is problem with static types:
>
> Lets assume that some method "m" which as parameter needs an object
> with both types of T1 and T2 which dont share any commonality (like be
> Displayable and Persistable).
> How do you define "m"?
> The only solution is to define it as m(Object o).
Why is that a problem?
Shayne Wissler
Ilja Preuß
> "Ilja Preuß" <pre...@disy.net> wrote in message
> news:c2poni$vo1$1...@stu1id2.ip.tesion.net...
>> Paul Campbell wrote:
>>
>>>> I don't see how that could go wrong with any implementation
>>>> of close().
>>>
>>> Your assuming that "close" is always the last thing you want to do
>>> with an object, that may not be the case e.g.
>>
>> I am not. The only responsibility of the method is to close the
>> object, if
>> it isn't null. You can use the method where and when you want.
>>
>> To reiterate, all the method does is
>>
>> public static void close(SomeType closable) {
>> if (closable != null) {
>> closable.close();
>> }
>> }
>>
>
> Any void return method by causes no state change is by definition
> redundent.
The method will cause the state change the object finds to be reasonable
when it receives the close message. The method assumes nothing at all about
what that state change will be or when it should be used. That is the
responsibility of the caller.
Take care, Ilja
Tsolak Petrosian
What you mean I cannot do anything useful with that object?
The usefulness comes from the contract that the Object passed will
implement these two types.
And there will not be any "ifs" if it were dynamic language but will
be for static languages in order to do cast and do pre condition
check.
Tsolak Petrosian
Isaac Gouy
> I fear I don't understand that example. Where in that code is a new
> interface retroactively added to a class definition?
My apologies, that example shows a new interface retroactively added
to an interface definition ;-)
See "Example 9.4. Abstract Interfaces" in the Nice Manual
http://nice.sourceforge.net/manual.html#ex:abstractInterface
//Make strings pass straight through as DEBUG info.
class java.lang.String implements LogEntry;
//Make throwables print a stack trace, plus a message
class nice.lang.Throwable implements LogEntry;
//We like to log requests, too
class javax.servlet.http.HttpServletRequest implements LogEntry;
Ilja Preuß
Well, hard to forget Java if you already have hundreds of thousands of lines
of working code...
Also, if I contrast the above code to that of a dynamically typed language
to get the same result, I'm not sure I actually *would* like to use Ada. But
that could just be the ignorance of the ignoramus... ;)
Take care, Ilja
Ilja Preuß
> (Both C++ and Java are statically typed. And weakly typed.)
As far as I can tell, Java actually is strongly typed (you get a
ClassCastException when you cast to a type an object doesn't support).
Modern C++ also has a similar option, as far as I know.
Take care, Ilja
Universe
Yes it does. I take C++ as strongly typed wrt statically bound classes.
The nice thing is that , you can get a fair amount of type "bending" using
run-time binding, and *still* have strong typing. OTOH one can encourage a
range of dynamic typing using conversion operators and of course there's
polymorphic adaptation using inheritance and template hierarchies. All
around C++ has an "accurately, wide latitude" type system and idiom.
Elliott
--
Though types only make sense relative to context, system worthwhile
types are *objectively* significant for the relative context.
--
Model the World to a Bright Future!
Paul Campbell
"Ilja Preuß" <pre...@disy.net> wrote in message news:c2q2t9$km0$1...@stu1id2.ip.tesion.net...
What "responsibility" is that then ? - what are the ramifications of the call
that the caller is taking responsibility for ?. If there arnt any why not just
comment out al the calls.
Paul C.
Isaac Gouy
> But there is absolutely no requirement that a class inherit from
> AbstractConcept in order to be used, or useful in the variable
> 'abstractConcept'.
By definition :-)
A statically checked language places type constraints on variables; a
dynamically checked language doesn't place type constraints on
variables.
> The AbstractConcept class literally does nothing in
> the SmallTalk code, the only possible use of the class is a repository
> for any shared implementation of the various subclasses, which could as
> easily be placed in a delegate, or duplicated in the clients.
One of your initial comments was "there is no central repository even
outlining the methods this particular abstract concept must be able to
support" - an abstract class can support that role
(subclassResponsibility).
> All of this means that I cannot easily tell if an object of a particular
> class is useful in the variable 'abstractConcept' unless I make a
> detailed study of what messages are sent to 'abstractConcept'.
Seems that you'd like to have an explicit interface definition?
http://www.jot.fm/jot/issues/issue_2002_05/article1/index_html
Isaac Gouy
> > In Nice, a statically checked language, (and other multimethod
> > languages) we can retroactively add a new interface to class
> > definitions.
> Which is effectively the same as making adaptor classes.
The aim is the same - making existing code usable in a different way.
The difference is that we don't have to write the adapter classes.
(Some patterns are ways to work around programming language
limitations.)
Tsolak Petrosian
Because to support the above requirments (which is not rare) you have
to lose compile time parameter type checking in static languages
(which makes static languages less benefical).
Tsolak Petrosian
Jochen Riekhof
> with both types of T1 and T2 which dont share any commonality (like be
> Displayable and Persistable).
> How do you define "m"?
> The only solution is to define it as m(Object o).
It seems you need another Type T3 that implements both T1, T2 and define
m(T3 o).
Maybe I got you wrong, so here the other possibilities:
or, m relies on a common subset of method signatures - then you need "T1
implements T3" and "T2 implements T3" and again define m(T3 o) (i.e. m
required TYPE T3 to be defined)..
else, if there is no commonly used method signature, m cannot safely call
any method and is useless.
To come back to the possible difficulties of a statically typed language as
opposed to a dynamically typed:
Apparently, when you have used T1 and T2 a lot of times in different places,
possibly one of them is in a public library used by 10000 developers
worldwide, a change of T1 to now implement T3 is quite difficult in a
statically typed language.
As you do not define any of the above interfaces explicitly in dynamic typed
languages you will not have any problem with your method m(o) - you happily
call your method on o, but OTOH you may see it is failing on runtime in case
o does not understand.
The above example is in fact one of the difficult problems with static
typing. Lots of Adapters, overloaded methods or a lot of conversions are
often the only way out.
Something like (Java)
interface MyXY {
double getX();
double getY();
}
import externalpackage.Point2D;
declare Point2D implements MyXY. //checked at compile time
would be probably quite helpful.
Ciao
...Jochen
Ilja Preuß
> See "Example 9.4. Abstract Interfaces" in the Nice Manual
> http://nice.sourceforge.net/manual.html#ex:abstractInterface
Ah, if I understand correctly, I would do:
abstract interface Closable {
void close();
}
public static void close(Closable closable) {
if (closable != null) closable.close();
}
class InputStream implements Closable;
and then could call
close(myInputStream);
Cool! :)
Thanks for the pointer, Ilja
Ilja Preuß
I agree.
The problem is when T1 and T2 *do* share commonalities, but the original
authors didn't embrace those.
Take care, Ilja
Universe
"Tsolak Petrosian" <tso...@yahoo.com> wrote in message
news:a052897d.04031...@posting.google.com...
> "Shayne Wissler" <thalesN...@yahoo.com> wrote in message
news:<eR%3c.7951$YG.69564@attbi_s01>...
> > "Tsolak Petrosian" <tso...@yahoo.com> wrote in message
> > news:a052897d.04031...@posting.google.com...
> >
> > > Here is problem with static types:
> > >
> > > Lets assume that some method "m" which as parameter needs an object
> > > with both types of T1 and T2 which dont share any commonality (like be
> > > Displayable and Persistable).
> > > How do you define "m"?
> > > The only solution is to define it as m(Object o).
> >
> > Why is that a problem?
> >
> >
> > Shayne Wissler
>
> Because to support the above requirments (which is not rare) you have
> to lose compile time parameter type checking in static languages
> (which makes static languages less benefical).
>
> Tsolak Petrosian
? Actually you have lost a LOT, especially using something so
vague and non-descript as 'Object'.
Think about it.
Elliott
Ilja Preuß
Paul, if I have code like
InputStream in = null;
OutputStream out = null;
try {
in = new ...
out = new ...
....
}
finally {
if (in != null) {
in.close();
}
if (out != null) {
out.close();
}
}
I'd really like to remove the duplication in the finally block. I currently
do this the following way:
InputStream in = null;
OutputStream out = null;
try {
in = new ...
out = new ...
....
}
finally {
StreamUtils.close(in);
StreamUtils.close(out);
}
In a dynamically typed language, I only need to implement one
StreamUtils.close for this purpose, and it would in fact also work for a
huge amount of similar objects (like Connections, Readers, Writers, Sockets,
etc.).
In Java, I have to define a new method for each base type, because there is
no common interface declaring the close method.
(It seems as if in Nice - and possibly other statically typed languages,
though none of the mainstream ones - I can add that interface later on, when
I need it.)
If hope this does make it clear to you what I am talking about. If not, I
have to resign - I have no further idea how to communicate this to you... :(
Take care, Ilja
JXStern
wrote:
>Here is problem with static types:
>
>Lets assume that some method "m" which as parameter needs an object
>with both types of T1 and T2 which dont share any commonality (like be
>Displayable and Persistable).
>How do you define "m"?
>The only solution is to define it as m(Object o).
m(T1 t1, T2 t2)
Ilja Preuß
> Apparently, when you have used T1 and T2 a lot of times in different
> places, possibly one of them is in a public library used by 10000
> developers worldwide, a change of T1 to now implement T3 is quite
> difficult in a statically typed language.
More importantly, you might not be able/allowed to change T1 or T2 - for
example because they are coming from a thirdparty library. In my
close-example in this thread this is the case - there are many classes in
the JDK which implement the close() method, by they don't implement a common
Closable interface.
> Something like (Java)
>
> interface MyXY {
> double getX();
> double getY();
> }
>
> import externalpackage.Point2D;
>
> declare Point2D implements MyXY. //checked at compile time
>
> would be probably quite helpful.
Yes. That seems to be exactly what Nice's "abstract interface"s are about.
Take care, Ilja
Robert C. Martin
<p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Robert C. Martin" <uncl...@objectmentor.com> wrote in message news:u7pu40lee08i8d7j6...@4ax.com...
>
>> >What constraints are you talking about? I know of no constraints imposed
>> >by static typed languages that don't also exist (implicitly) in dyanamic
>> >typed languages.
>>
>> Imagine that you have a derivative that has a method. You are adding
>> code to that method and decide that you need to throw an exception.
>> No other implementations of that method in other derivatives throw
>> exceptions.
>
>Well thats one hell on an LSP violation - as I'm sure you know :-).
Only if you did something sneaky like promote the exception to Error
and throw it unchecked. Otherwise, the compiler won't allow the LSP
violation.
It's possible that the developers never anticipated the need for the
exception, and only discovered the need much later. In order to avoid
the LSP violation they have to add the "throws" clause to the base
class method. Ouch!
Dave Harris
> > The Petzold-style message-loop may be hard to unit test; I don't
> > know. If it is, I'd say that was an argument for not using Petzold
> > style.
>
> A post<=>dispatch message loop is an integral part of the way the
> Windows OS operates.
A "Petzold-style" loop would be a single routine; hundreds, sometimes
thousands of lines long. It would contain all the code for one window and
much knowledge of Windows message formats. There would be many typecasts
of the WPARAM to HDC kind. Typically, buried somewhere in it would be a
comment saying, "I can't believe I used a goto!". And every window in the
app would have its own loop, created by copy&paste.
The corresponding loop in a modern app is very different. It will, for
example, separate the code which is specific to one window from code which
is common to all. This separation makes testing easier.
-- Dave Harris, Nottingham, UK
Robert C. Martin
wrote:
>Dmitry A. Kazakov wrote:
I don't know Ada, but I *think* I understand it as:
package Closable_Things;
interface Closable {
void close();
static void Close(Closable c) {
if (c != null)
c.close();
}
}
I took out the IsNull boolean since that's done a different way in
Java (is it really done Dmitry's way in Ada?). I also took out the
Close/DoClose split. It didn't make a lot of sense to me. Finally, I
can't remember if you can put static methods in an interface. If not,
-- well you get the idea.
If I have interpreted the Ada properly (doubtful) then this doesn't
solve the problem that Ilja is trying to solve since it forces all
objects passed to Closeable.close() to be derived from type Closeable.
Robert C. Martin
<mai...@dmitry-kazakov.de> wrote:
>On Wed, 10 Mar 2004 23:21:57 -0600, Robert C. Martin
><uncl...@objectmentor.com> wrote:
>
>>On Wed, 10 Mar 2004 12:55:33 +0000 (UTC), Peter Hermann
>><ica...@sinus.csv.ica.uni-stuttgart.de> wrote:
>>
>>>Robert,
>>>I know you since more than one decade as a strongheaded Ada ignorer.
>>
>>I am certainly an Ada ignorer. The ignorance is not strongheaded
>>however. I'd like to learn Ada. I've just never had the need.
>>
>>>Nevertheless I read your whole contribution and again shook my head.
>>>All your needs are fulfilled by Ada, hands down.
>>
>>I don't know, but I thought that large Ada systems might have build
>>times in excess of one second; or that if I change a function
>>signature in one Ada module I might have to recompile many other
>>modules -- even those that don't call it. Am I mistaken?
>You have to recompile the modules depending on the module which
>interface contains the signature.
Then Ada does not fulfill the issue that I was referring to.
>If that modules do not call the
>function, then the design with respect to how decomposition into
>modules was made, is not good, provided that the function has to
>undergo permanent signature changes (?) being simultaneously a part of
>a module interface!
Consider, for example, the Stack class. It has both a push and a pop
method. Interestingly enough the modules that call push are often
distinct from the modules that call pop. If I change the signature of
the push method, I still have to recompile all the folks who call pop.
In a dynamically typed language I don't.
>Altogether this example is quite abstract. In
>practice, due to strict checks imposed by the language, you will
>probably unable to get your module interface compiled, if it contains
>a "crazy" function falling out of design. Once you get the interface
>right, you will unlikely need to change it ten times per day using it
>in hundreds of other modules at the same time. When still the
>compilation time became an issue, one should better scrap the whole
>project.
Compilation time of over one second *is* an issue. It changes the
ratio of the amount of code I write to the frequency of testing. I'd
like to run my tests after *every* new line of code I write. In a
dynamic language, I can.
Please remember that I am NOT writing in a dynamic language at the
moment. Most of my serious work is done in Java, C#, or C++. I am
simply speculating on the effect that TDD will have on language
preference in the future.
Robert C. Martin
wrote:
>Robert C. Martin <uncl...@objectmentor.com> wrote in message news:<bt6v409vm5cf909oq...@4ax.com>...
>> On Wed, 10 Mar 2004 12:55:33 +0000 (UTC), Peter Hermann
>> <ica...@sinus.csv.ica.uni-stuttgart.de> wrote:
>>
>> >Robert,
>> >I know you since more than one decade as a strongheaded Ada ignorer.
>>
>> I am certainly an Ada ignorer. The ignorance is not strongheaded
>> however. I'd like to learn Ada. I've just never had the need.
>>
>> >Nevertheless I read your whole contribution and again shook my head.
>> >All your needs are fulfilled by Ada, hands down.
>>
>> I don't know, but I thought that large Ada systems might have build
>> times in excess of one second; or that if I change a function
>> signature in one Ada module I might have to recompile many other
>> modules -- even those that don't call it. Am I mistaken?
>
>Rational had an Ada compiler that did not recompile modules that did
>not truly need the modifications.
Yes, the R1000. I have been told that it was a very nice system.
Actually, it recompiled any line of code that depended on a
declaration that was changed. This greatly minimized the impact and
build time of a change.
Dick Gabriel tried to do something similar for C++ about a decade ago,
but it didn't catch on. Rational tried again with it's Apex project,
but I haven't heard much about it.
IntelliJ *could* do it, but I don't think it does. To the best of my
knowledge it falls back on the JDK compiler (or whatever compiler you
choose). In Java, however, compiles are very fast. Longer than a
second perhaps, but seldom as long as a minute.
>I don't know if it still exists (I
>haven't been able to use their compilers for a while), but there is
>nothing in the language that prohibits compilers from this. When I
>asked one vendor why they didn't support that type of feature they
>said that compilation times were so fast it wasn't necessary. I
>disagree with that vendor's position.
So do I. To get that behavior in a static language you have to have a
very special kind of compiler. Nobody seems to want to write that
kind of compiler. The behavior comes for free in a dynamically typed
language. Moreover, in a dynamically typed language the impact of a
source code change is much smaller even than in an R1000 style
compiler.
Robert C. Martin
>
>Robert C. Martin wrote:
>> The question is whether it is enough for each of them individually to
>> make the same decision I did. I'm not asking if this is a good thing
>> or not. If TDD continues to be practiced more and more, will each
>> individual relax their reliance on static type checking?
>
>What you would do personally matters for your personal programming.
>My focus is always on pretty complex projects. In that context
>it is the project and the characteristics of the group and
>management that will decide. It can't be an individual choice,
>no more than language selection in a project is an individual choice.
Granted. But the team choice will be a function of the individual
preferences. If those preferences change over time the way I think
they will, more and more teams will make the decision in the dynamic
direction.
>> I, on the other hand, have found that writing unit tests concurrently
>> with code is less burdensome than not writing them, even in very
>> simple systems. This is a personal decision that applies to me and
>> may not apply to everyone.
>
>Burdensome is a big word that can mean very different things
>to different people. It implies an assessment of tradefoffs
>and values. I find it hard to believe you can determine a policy
>absolutely for all circumstances.
[snip]
>A team of experienced people who get to conscientiously do anything
>will deliver the project faster, cheaper, and better. I have
>seen this many times. When a team consists partly of
>unconscientious people or are who are not allowed to act
>conscientiously, then it becomes very difficult to succeed
>period.
Which suggests a simple policy which may be absolute for all
circumstances. ;-)
>> 200 years ago you'd have had trouble finding doctors who bothered to
>> wash their hands before surgery. Nowadays you won't find one who
>> doesn't *diligently* wash his hands.
>
>And do you find studies supporting this practice? Interestingly
>i recall Dr Dean Edell saying there wasn't.
Are you going to go to a doctor with dirty hands? Or do you buy the
current position on this issue? Remember I'm not talking about proof.
I'm talking about preference.
>>25 years ago you'd have had
>> trouble finding a software developer who didn't use goto. Nowadays
>> they are pretty rare. Practices change, and it doesn't really take
>> that long for them to change. I think it's possible that in a few
>> years TDD could be viewed as a standard of professional behavior.
>Good is standard behaviour
I wish that were true.
Thomas Gagné
Robert C. Martin wrote:
>On Thu, 11 Mar 2004 11:09:08 -0000, "Paul Campbell"
><p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote:
>
>
>
>> <snip>
>>
>>Well thats one hell on an LSP violation - as I'm sure you know :-).
>>
>>
>
>Only if you did something sneaky like promote the exception to Error
>and throw it unchecked. Otherwise, the compiler won't allow the LSP
>violation.
>
>It's possible that the developers never anticipated the need for the
>exception, and only discovered the need much later. In order to avoid
>the LSP violation they have to add the "throws" clause to the base
>class method. Ouch!
>
>
>
It's not my custom to advocate anything Java but I think that's why
Bruce Eckel suggests subclassing RuntimeException instead. You don't
have to declare it or its subclasses as being thrown--yet you can still
catch it. Reminds me of Smalltalk.
--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org
Robert C. Martin
<p.au.l.ca...@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Tsolak Petrosian" <tso...@yahoo.com> wrote in message news:a052897d.04031...@posting.google.com...
>
>> Here is problem with static types:
>>
>> Lets assume that some method "m" which as parameter needs an object
>> with both types of T1 and T2 which dont share any commonality (like be
>> Displayable and Persistable).
>> How do you define "m"?
>> The only solution is to define it as m(Object o).
>
>If they dont share any commonality then then surely there is *nothing* you
>can usefully do with such an object other than an explicity dispatch using
>an if statement to test its type.
It's not that they don't share a commonality, they do. However, in a
dynamically typed language you don't have to declare the commonality
in a separate structure. In a statically typed language you have to
declare the commonality in an interface or an abstract class; you also
have to use a relationship like inheritance to bind the two common
classes to this separate structure. This coupling -- and it is a very
strong coupling -- is not needed in a dynamically typed language.
Justin Farley
> Consider, for example, the Stack class. It has both a push and a pop
> method. Interestingly enough the modules that call push are often
> distinct from the modules that call pop. If I change the signature of
> the push method, I still have to recompile all the folks who call pop.
>
> In a dynamically typed language I don't.
You don't have to recompile the folks in Java either, assuming those folks
/only/ call the unchanged 'pop()'.
Static typing does not necessitate static binding AFAICT.
--
Justin
Shayne Wissler
"Tsolak Petrosian" <tso...@yahoo.com> wrote in message
news:a052897d.04031...@posting.google.com...
> "Shayne Wissler" <thalesN...@yahoo.com> wrote in message
news:<eR%3c.7951$YG.69564@attbi_s01>...
> > "Tsolak Petrosian" <tso...@yahoo.com> wrote in message
> > news:a052897d.04031...@posting.google.com...
> >
> > > Here is problem with static types:
> > >
> > > Lets assume that some method "m" which as parameter needs an object
> > > with both types of T1 and T2 which dont share any commonality (like be
> > > Displayable and Persistable).
> > > How do you define "m"?
> > > The only solution is to define it as m(Object o).
> >
> > Why is that a problem?
> >
> >
> > Shayne Wissler
>
> Because to support the above requirments (which is not rare) you have
> to lose compile time parameter type checking in static languages
> (which makes static languages less benefical).
Well, by this argument dynamic typing is even worse, since it loses compile
time checking all the time and not just sometimes. But I thought you were
attempting to argue for dynamic typing, so I fail to see the logic in your
position.
Shayne Wissler
Isaac Gouy
> Cool! :)
Even cooler this already exists:
let f = new FileOutputStream("hello.txt");
using(f){
f.write("Hello, world!".getBytes());
}
is equivalent to:
let f = new FileOutputStream("hello.txt");
try {
f.write("Hello, world!".getBytes());
}
finally{
f.close();
}
To make OutputStreams work with 'using' this code was added:
class java.io.OutputStream implements Disposable;
dispose(OutputStream s) = s.close();
Universe
news:4050b91a$1...@news.totallyobjects.com...
> > Lets assume that some method "m" which as parameter needs an object
> > with both types of T1 and T2 which dont share any commonality (like be
> > Displayable and Persistable).
> > How do you define "m"?
> > The only solution is to define it as m(Object o).
>
> It seems you need another Type T3 that implements both T1, T2 and define
> m(T3 o).
Right, at least that's a major oft suitable alternative. In C++, one
frequently, has both
inherit a "mixin'" that provides narrowly focused tasks, typically mostly
orthogonal
to the essence of the type abstraction of the classes doing the inheriting
of the "mixin'". Even
to the point that classes in the situation, might inherit multiply--on the 1
hand wrt their
main abstraction quiddity/qua/nature, "typehood" <g>, and other the other
hand inheriting
to pick up requisite "mixin'" capability.
That way both T1 and T2 could easily be told to display, serialize, etc.
themselves
appropriately.
Or one might have both delegate to handlers, or use a Visitor with just
those orthogonal tasks.
[Visitor *does* have correct uses. :- ]
> Maybe I got you wrong, so here the other possibilities:
> or, m relies on a common subset of method signatures - then you need "T1
> implements T3" and "T2 implements T3" and again define m(T3 o) (i.e. m
> required TYPE T3 to be defined)..
> else, if there is no commonly used method signature, m cannot safely call
> any method and is useless.
Yes, a *definite* possibility it's wise to check for in similar
circumstances.
> To come back to the possible difficulties of a statically typed language
as
> opposed to a dynamically typed:
> Apparently, when you have used T1 and T2 a lot of times in different
places,
> possibly one of them is in a public library used by 10000 developers
> worldwide, a change of T1 to now implement T3 is quite difficult in a
> statically typed language.
> As you do not define any of the above interfaces explicitly in dynamic
typed
> languages you will not have any problem with your method m(o) - you
happily
> call your method on o, but OTOH you may see it is failing on runtime in
case
> o does not understand.
>
> The above example is in fact one of the difficult problems with static
> typing. Lots of Adapters, overloaded methods or a lot of conversions are
> often the only way out.
Or "uses" which in C++ is this "vein".
And generally with them all, often enuff loads mo' static type system
robustness as well.
> Something like (Java)
>
> interface MyXY {
> double getX();
> double getY();
> }
Kinda like the above MI in C++.
> import externalpackage.Point2D;
>
> declare Point2D implements MyXY. //checked at compile time
>
> would be probably quite helpful.
>
>
> Ciao
>
> ...Jochen
Elliott
--
This behavior of overlooking or deprecating the system approach and
scientific method in some cases, is at best, pathetically, poor
academics, and sloppy engineering. And in a number of other cases
where dollars matters most, it's dishonest opportunism and an
abrogation of intellectual integrity.
Isaac Gouy
> Yes. That seems to be exactly what Nice's "abstract interface"s are about.
"A kind is a name that represents a characteristic shared by a set of classes."
If you're interested in the technical detail:
"Using kinds to type partially-polymorphic methods" Daniel Bonniot
http://www.elsevier.com/gej-ng/31/29/23/132/23/25/75003.pdf
Tsolak Petrosian
The "m" is defined in superinterface but contcrete implementation
might need only T1, other T1 and T2.
As an example:
public interface DisplayManager{
public diplay(Object o);
}
public class PersonDisplayManager implements DisplayManager{
public display(Object o){
if (o instanceof Person) //render person
if (o instanceof AddressHolder) //render address
}
}
public class AddressDisplayManager implements DisplayManager{
public display(Object o){
if (o instanceof AddressHolder) //render address
}
}
Tsolak Petrosian
So for any group of type we will declare holder type?
Tsolak Petrosian
Tsolak Petrosian
Whats the problem in that case (when T1 and T2 *do* share commonalities)?
Tsolak Petrosian
JXStern
wrote:
>> >The only solution is to define it as m(Object o).
>>
>> m(T1 t1, T2 t2)
>
>The "m" is defined in superinterface but contcrete implementation
>might need only T1, other T1 and T2.
I begin to see your problem.
The problem is one of accidentally raising properties from subclasses
up into the base classes so you get polymorphic dispatch for
everything from one spot.
Well, maybe that's just not appropriate. Don't put the virtual
interface in the base class. This should not cause a problem, since
the callers apparently will be aware of the sub-tree their objects are
in. But OK, you'll have a collection of many types in some utility
routine, and want to iterate through generically, polymorphizing (or
downcasting) all the way. Shrug. Well, either you define combo
classes to hold whatever the union of all subtypes are every time you
have this pattern, or you use a generic object type as you did in your
examples, ... actually that's not 'or' that's 'and'.
Well, my solution for such problems has long been that if it looks
crufty in "pure" OO-speak, don't use pure OO-speak. I'd still move
the interface down and keep specific types on the parameters and deal
with the coding consequences.
--
Is it true that in Python you don't even have this problem, as all the
checking is purely at runtime anyway? I guess that was your point
from the start, and if so, I agree -- with dynamic type-checking you
don't need the virtual function in the base to polymorphize freely at
runtime. Kewl.
Joshua Stern
Tsolak Petrosian
> "Tsolak Petrosian" <tso...@yahoo.com> wrote in message
> news:a052897d.04031...@posting.google.com...
> > "Shayne Wissler" <thalesN...@yahoo.com> wrote in message
> news:<eR%3c.7951$YG.69564@attbi_s01>...
> > > "Tsolak Petrosian" <tso...@yahoo.com> wrote in message
> > > news:a052897d.04031...@posting.google.com...
> > >
> > > > Here is problem with static types:
> > > >
> > > > Lets assume that some method "m" which as parameter needs an object
> > > > with both types of T1 and T2 which dont share any commonality (like be
> > > > Displayable and Persistable).
> > > > How do you define "m"?
> > > > The only solution is to define it as m(Object o).
> > >
> > > Why is that a problem?
> > >
> > >
> > > Shayne Wissler
> >
> > Because to support the above requirments (which is not rare) you have
> > to lose compile time parameter type checking in static languages
> > (which makes static languages less benefical).
> >
> > Tsolak Petrosian
>
> ? Actually you have lost a LOT, especially using something so
> vague and non-descript as 'Object'.
>
> Think about it.
>
> Elliott
But I still can use reflection make the vague 'Object' to become something specific.
Tsolak Petrosian
Isaac Gouy
> Yes, I wrote this up in a blog on artima:
> http://www.artima.com/weblogs/viewpost.jsp?thread=4639
Thanks, for humouring my curiousity and reposting here.
> I've been a statically typed bigot for quite a few years. I learned my
> lesson the hard way while using C. Too many systems crashed in the
> field due to silly typing errors.
Long ago I chose to use a Modula-2 compiler which clearly indicated
compile-time errors which the C compiler seemed unsure about. I feel
your pain ;-)
-snip-
> About two years ago I noticed something. I was depending less and less
> on the type system for safety. My unit tests were preventing me from
> making type errors. The more I depended upon the unit tests, the less
> I depended upon the type safety of Java or C++ (my languages of
> choice).
Someone on artima probably mentioned that these aren't great examples
of statically checked languages :-)
> I was not entirely surprised when I found that type issues
> simply never arose. My unit tests kept my code on the straight and
> narrow. I simply didn't need the static type checking that I had
> depended upon for so many years.
In response to the original article, Chad Fowler wrote:
"A lot of us "bigots" just need something that makes dynamic typing
feel permissable for the short time it takes to realize that there was
never anything to worry about."
Maybe there never was anything to worry about, for any group of
reasonably diligent programmers ;-)
> I also realized that the flexibility of dynamically typed languages
> makes writing code significantly easier. Modules are easier to write,
> and easier to change. There are no build time issues at all. Life in a
> dynamically typed world is fundamentally simpler.
That would depend on what we were trying to achieve.
Implementing an expressive type system seems to be a hard problem.
Perhaps the genius of dynamically typed languages is that they simply
ignore that problem and spend their efforts on other aspects of
language design.
> Now I am back programming in Java because the projects I'm working on
> call for it. But I can't deny that I feel the tug of the dynamically
> typed languages. I wish I was programming in Ruby or Python, or even
> Smalltalk.
It's not just that Smalltalk has dynamic-type-checking and Java has
static-type-checking. In 'Everything is an Object' Smalltalk we have a
unified type system; in 'Everything is an Object' Java we have
primitive types and class types and array types. In OO Smalltalk we
have anonymous functions; in OO Java we don't. etc etc
There are more coherent statically-checked-languages than Java, and
some of them even run on a standard JVM ;-)
Isaac Gouy
> > > (Both C++ and Java are statically typed. And weakly typed.)
Let's go back to school :-)
http://www.stanford.edu/class/cs242/slides/
"Not safe: BCPL family, including C and C++
• Casts, pointer arithmetic
Almost safe: Algol family, Pascal, Ada.
• Dangling pointers.
– Allocate a pointer p to an integer, deallocate the memory referenced
by p, then later use the value pointed to by p
– No language with explicit deallocation of memory is fully type-safe
Safe: Lisp, ML, Smalltalk, and Java
• Lisp, Smalltalk: dynamically typed
• ML, Java: statically typed"
Universe
I don't really know know about your Display technology, but typically
DisplayManager
should not require being subclassed in this situation.
Most physical displays can render images of people and address text equally
well, so
you wouldn't have 2 diff kinds of displays, which is what I think your code
would
IMPLY to most engineers reading it.
OO polymorphism and is overkill for this. You really only need a properly
coded 'if'/'switch'
statement. And if the only reason for the classes is to get the proper
display, you really don't
need the classes.
AddressHolder is simply a data container and thus being a class
overcomplicates things. Also
unless Person manages and maintains some use case vital behavior about
Person, it can also
be simply be a data container and not a class.
To do the above, you seem only to need free-standing code or if your OOPL
supports it like
C++,a function. [This is pseudo OOPL, meant for OO community wide IDEA
discussion. ]
//VARS:
struct Address
{
string AddrLine1;
string AddrLine2;
string AddrLine3;
string AddrLine4;
int Region;
};
struct Person
{
int Title;
string First;
string Middle;
string Last;
string Suffix;
Address PersonAddress;
};
Display dispLocationX, dispLocationY;
//FUNCS:
DisplayProgramData(Person PDat, Address ADat)
{
if (ADat Not Null)
{
display(PDat);
display(ADat);
}
else
{
display(PDat);
};
};
If you truly use 2 different, say positioned displays, and Person records
only are
rendered on a display at say LocationX with its Address record, whereas it
only an Address record is being rendered then it is displayed at LocationY:
[This Tsolak is what your code *implies*. Would be rare though.]
DisplayProgramData(Person PDat, Address ADat)
{
if (ADat Not Null)
{
displayX(PDat);
displayX(ADat);
}
else
{
displayY(PDat);
};
};
My .02
Hope this somehow helps us all gain in type knowledge.
Elliott
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
Peter Ammon
> In article <pt2v40dv3n3gvp43b...@4ax.com>,
> Ron Jeffries <ronje...@REMOVEacm.org> wrote:
>
>
>>On Wed, 10 Mar 2004 12:53:45 GMT, "Daniel T." <postm...@eathlink.net>
>>wrote:
>>
>>
>>>>However, because of the artificial constraints often imposed, static
>>>>typing
>>>>can
>>>>also force one to a design which is less natural, less rational, than one
>>>>would
>>>>use in a more dynamic language.
>>>
>>>What constraints are you talking about? I know of no constraints imposed
>>>by static typed languages that don't also exist (implicitly) in dyanamic
>>>typed languages.
>>
>>I'm thinking largely of the constraints around needing to declare everything
>>in
>>advance, which leads to tons of declared interfaces, and objects that want to
>>inherit from lots of them. Offhand, I can't think of anything I couldn't
>>program, but I find that the need to do all that declaration makes some
>>solutions harder to get to in practice, even though they are technically
>>possible.
>>
>>Does that help to clarify? If not, inquire further ...
>
>
> I agree, it can be a pain to have to actually write down all the various
> interfaces that are running around in your head while coding. Often
> times, programmers using static typed languages don't bother and then
> curse the language when they can't easily plug in their new class. On
> the other hand...
>
> There is real value in the "compilable comment"; code that is ment to
> help clarify the design of the system, which the compiler can check.
> That's what interfaces are. They put more knowledge of the design *into*
> the design, rather than only in the designer's heads.
>
> You see, I believe that all thoses things that need to be "declared in
> advance" in a static typed language, also need to be at least conceved
> of in advance in a dyanimic typed language, even if they don't need to
> be explicitly expressed in the code.
I disagree. Consider the Envelope/Letter pattern. In a static
language, the Envelope must be tightly coupled to whatever it contains
(since the Envelope's interface must be a superset of the Letter's
interface). In a dynamic language, you can use message forwarding to
decouple them entirely.
This means that dynamic languages let you implement thread
synchronization wrappers or logging wrappers (for example) without
needing to know the interface of the contained Letter in advance.
Static languages force you to know the contained interface in advance.
--
Pull out a splinter to reply.
Universe
"Isaac Gouy" <ig...@yahoo.com> wrote in message
news:ce7ef1c8.0403...@posting.google.com...
> Robert C. Martin <uncl...@objectmentor.com> wrote in message
news:<cmos401b4aa3lu33q...@4ax.com>...
>
> > Yes, I wrote this up in a blog on artima:
> > http://www.artima.com/weblogs/viewpost.jsp?thread=4639
>
> Thanks, for humouring my curiousity and reposting here.
>
>
> > I've been a statically typed bigot for quite a few years. I learned my
> > lesson the hard way while using C. Too many systems crashed in the
> > field due to silly typing errors.
>
> Long ago I chose to use a Modula-2 compiler which clearly indicated
> compile-time errors which the C compiler seemed unsure about. I feel
> your pain ;-)
Right, actually C *versus* C++ is very weakly typed. One can coerce/assign
almost
anything to anything. At least the C before Standard C. So I kinda wonder
how
RCM was concretely getting "blogged" by C.
Compared to C++, I enjoyed a "C breeze" type assignment wise with M$C 5.0
(mid to late 80's) and M$C 4.X down.
M$C 5.0 was a pretty nice tool imo. Comprehensive, but not bloated. At
least for
a Winblows developer. To me that was the heyday of Structured C. I learned
all
kinds of C and Structured techniques.
Gyyyaaddd!! I loved then and love now reading highly complex, yet well
Structured C code!!!
[And it galls me to no end, that some folk whom I can tell have never a full
page
of THAT kind of C, go on and on, time after time giving upside down,
locopullooza,
yet supposed seriously studied TRIPE about complex, structured code, C
code.]
Stuff that would be a genuine disaster if actually followed. And some don't
know
that and are "snowed" by words, "sites", forests, etc and think that makes
those
folk giving advice well placed to give advice about OO sw engineering. Not
only
is the Structured advice mostly a cracked pot, but so is their large,fancy,
glass, chrome
restaurant that really has a truck behind the kitchen facade and hurried
standing orders to
the greasy spoon next door.
Elliott
Universe
> "Universe" <univ...@tAkEcovadOuT.net> wrote in message
news:<d4a9a$4050a6df$97cff003$32...@msgid.meganewsservers.com>...
>
> > > > (Both C++ and Java are statically typed. And weakly typed.)
>
> Let's go back to school :-)
> http://www.stanford.edu/class/cs242/slides/
************************************
* Yes. So you get your messge reply QUOTING RIGHT.
*
* I ain't said a darn thing there except these 2 sentences. Elliott
************************************
> "Not safe: BCPL family, including C and C++
> . Casts, pointer arithmetic
>
> Almost safe: Algol family, Pascal, Ada.
> . Dangling pointers.
> - Allocate a pointer p to an integer, deallocate the memory referenced
> by p, then later use the value pointed to by p
> - No language with explicit deallocation of memory is fully type-safe
>
> Safe: Lisp, ML, Smalltalk, and Java
> . Lisp, Smalltalk: dynamically typed
> . ML, Java: statically typed"
Universe
> Robert C. Martin <uncl...@objectmentor.com> wrote in message
news:<cmos401b4aa3lu33q...@4ax.com>...
>
> > Yes, I wrote this up in a blog on artima:
> > http://www.artima.com/weblogs/viewpost.jsp?thread=4639
>
> Thanks, for humouring my curiousity and reposting here.
>
>
> > I've been a statically typed bigot for quite a few years. I learned my
> > lesson the hard way while using C. Too many systems crashed in the
> > field due to silly typing errors.
>
> Long ago I chose to use a Modula-2 compiler which clearly indicated
> compile-time errors which the C compiler seemed unsure about. I feel
> your pain ;-)
See and why can you feel his pain falsely making out/implying clearly C to
be statically typed while the false stuff you quote attribted to me, you
gave a mini-lesson on.
******************************
* That is what I mean about people being "snowed" by appearance and false
* authority!
*
* Elliott
******************************
Universe
> On Wed, 10 Mar 2004 22:21:05 -0800, thoff <t...@possibility.com> wrote:
>
> >
> >Robert C. Martin wrote:
> >> The question is whether it is enough for each of them individually to
> >> make the same decision I did. I'm not asking if this is a good thing
> >> or not. If TDD continues to be practiced more and more, will each
> >> individual relax their reliance on static type checking?
> >
> >What you would do personally matters for your personal programming.
> >My focus is always on pretty complex projects. In that context
> >it is the project and the characteristics of the group and
> >management that will decide. It can't be an individual choice,
> >no more than language selection in a project is an individual choice.
> Granted. But the team choice will be a function of the individual
> preferences.
Only indirectly secondarily over time. Plus XP'ers revealing the "backend"
and
consultant oriented nature of their experience and conditions, never fail to
consider that the design on what languages and other tools, where to use
them, when to use them, how to use them with mature, scientific, repeatable
teams, firms, sw engineers is 90% the outcome of tradeoffs amongst a myriad
of factors.
And MOSTLY NOT JUST BY CODERS, but at their ALL key direct players at
their level-
ANAfrigginLYSTS, domain experts, firm IT coders, toolsmiths, process people,
network
people, database people, system and subsystem architects, etc and so to the
ad
infinitum dismay of many (not all) self-centered, massive, insecure ego XP,
prima donna, elitists, CODE BIGOTED & MYOPIC XP'ers.
And ALL of the above listed level only moves on sub-decisions coming out of
WHOLE organization tactical and STRATEGIC decision making. Some of the
above, esp. domain experts, analysts, and other senior IT staff are in on
this
org. tactical and strategic thinking. Org goals, resource allocation and a
WWWHHHHOOOOLLLLEEEEE bunch of other stuff that many (not all)
XP'ers are CLUELESS and worse CARELESS ABOUT oriented.
Elliott
--
The thing is that doing holistic investigation and creating
holistic plans at all times takes us as far ahead in terms of
understanding, as rapidly as possible while enabling us to
implement at all times in a way that supports what we
know will shortly be incorporated.
Universe
"Universe" <univ...@tAkEcovadOuT.net> wrote:
> "Tsolak Petrosian" <tso...@yahoo.com> wrote:
> > > tso...@yahoo.com (Tsolak Petrosian) wrote:
> > > >Here is problem with static types:
> > > >
> > > >Lets assume that some method "m" which as parameter needs an object
> > > >with both types of T1 and T2 which don't share any commonality (like
be
> > > >Displayable and Persistable).
> > > >How do you define "m"?
> > > >The only solution is to define it as m(Object o).
> "Tsolak Petrosian" <tso...@yahoo.com> wrote: [CONT.]
> > The "m" is defined in superinterface but concrete implementation
> > might need only T1, other T1 and T2.
> >
> > As an example:
> >
> > public interface DisplayManager{
> > public display(Object o);
> > }
> >
> > public class PersonDisplayManager implements DisplayManager{
> > public display(Object o){
> > if (o instanceof Person) //render person
> > if (o instanceof AddressHolder) //render address
> > }
> > }
> >
> >
> > public class AddressDisplayManager implements DisplayManager{
> > public display(Object o){
> > if (o instanceof AddressHolder) //render address
> > }
> > }
> //VARS:
>
> struct Address
> {
> string AddrLine1;
> string AddrLine2;
> string AddrLine3;
> string AddrLine4;
> int Region;
> };
>
> struct Person
> {
> int Title;
> string First;
> string Middle;
> string Last;
> string Suffix;
> Address PersonAddress;
> };
>
> Display dispLocationX, dispLocationY;
>
> //FUNCS:
>
> DisplayProgramData(Person PDat, Address ADat)
> {
> if (ADat Not Null)
> {
> display(PDat);
> display(ADat);
> }
> else
> {
> display(PDat);
> };
> };
***RATHER***
DisplayProgramData(Person PDat, Address ADat)
{
if (PDat)
{
display(PDat);
display(ADat);
}
else
{
display(ADat);
};
};
> If you truly use 2 different, say positioned displays, and Person records
> only are
> rendered on a display at say LocationX with its Address record, whereas it
> only an Address record is being rendered then it is displayed at
LocationY:
> [This Tsolak is what your code *implies*. Would be rare though.]
>
> DisplayProgramData(Person PDat, Address ADat)
> {
> if (ADat Not Null)
> {
> displayX(PDat);
> displayX(ADat);
> }
> else
> {
> displayY(PDat);
> };
> };
***RATHER***
DisplayProgramData(Person PDat, Address ADat)
{
if (PDat)
{
displayX(PDat);
displayX(ADat);
}
else
{
displayY(ADat);
};
};
Elliott
Vladimir Levin
I'm sure I am being thick, but what's wrong with defining a
Displayable interface, e.g.
public interface Displayable {
public void display(Context c);
}
public class Person implements Displayable { ... }
public class AddressHolder implements Displayable { ... }
Robert C. Martin
bran...@cix.co.uk (Dave Harris) wrote:
>univ...@tAkEcovadOuT.net (Universe) wrote (abridged):
>> > The Petzold-style message-loop may be hard to unit test; I don't
>> > know. If it is, I'd say that was an argument for not using Petzold
>> > style.
>>
>> A post<=>dispatch message loop is an integral part of the way the
>> Windows OS operates.
>
>A "Petzold-style" loop would be a single routine; hundreds, sometimes
>thousands of lines long. It would contain all the code for one window and
>much knowledge of Windows message formats. There would be many typecasts
>of the WPARAM to HDC kind. Typically, buried somewhere in it would be a
>comment saying, "I can't believe I used a goto!". And every window in the
>app would have its own loop, created by copy&paste.
Bleah! Don't remind me of those bad old days.