From: "Brett H. Williams" <brett_williams@...>
Date: 2003-04-13T00:49:00+09:00
Subject: Re: Does dynamic typing make it easier to place an object in a container?

On Apr 12, Ryan Pavlik wrote:
> > For a great explanation, see Pragmatic Dave's article at:
> > 
> > http://www.pragmaticprogrammer.com/cgi-local/pragprog?JavaIsUntyped
> 
> This is even worse.  Java is strongly, statically typed.  The fact
> you can say Object o = new OtherThing is neither "untyped" (weak typing)
> or dynamically typed.  Given class OtherThing inherits from Object,
> this assignment is correct: OtherThing _is_ an Object.  Static typing
> rules are unbroken, and since we're dealing with types, we have, by
> definition, strong typing.
> 
> An analogy to this page would be looking at C++ and saying, "well, until
> you refer to an object, it's just a big blotch of memory, so Neo,
> There Is No Type."  (Of course, at some point, everything is just memory,
> but reducing things to the lowest common denominator isn't really
> correct and certainly isn't useful.)  Another way would be looking at
> C (or C++) and saying you can refer to everything as a void*, so
> it's weakly dynamically typed.

While I agree with your statement about the lowest common denominator, I must
disagree from a practical standpoint.  Do you commonly treat objects as void *
and pass them around as such in C++?  I hope not.  In Java, however (at least
until 1.5 comes out and is widely distributed), much of the time you _do_ in
fact pass things around as Objects due to the containers, just like Dave's note
above.

The "lowest common denominator" you refer to is very common in Java.

> These language features all let you do some things similar to dynamic
> typing or weak typing, but that doesn't make the language dyamically
> or weakly typed.

Not literally.  But some of the advantages of static typing are in practice
diluted when using collections in Java.  And what program doesn't make heavy
use of collections?  I think that was the point--the headline to the note is
more for drawing attention to it.

Very commonly these advantages are reclaimed by extending the collection class
and automating the casts within that class.  But this is a pain, particularly
if you need your collection to perform these casts for a complete interface (as
opposed to just overriding the methods you care about).

Certainly this is widely recognized within the Java community, hence the
approach taken with generics in 1.5.

> This message has gone on far too long already, but I'll address the
> question in the subject line shortly.  With OOP, as you can refer to
> an object by a generic parent class, it's really no more difficult
> in a static language to make a container than in a dynamic one.
> Either way you can filter your classes to make homogenous containers,
> or allow heterogenous containers.

Perhaps in theory, or in some languages (I can't speak for what I don't
know)--but not in C++ or Java, which is likely what the original article was
referring to.  It is more difficult to use containers in those languages.  You
either use the generic parent class (Object in Java, except that doesn't work
with int, char, float etc, another step must be taken) and cast, or create some
templates in C++ (there is no generic parent class).  Neither of these are even
close to being as easy to do as a = [ "1", 2 ].  Possible, and certainly
commonly done, but not as easy.

Just my $.02.

-- 
Brett