Duck typing alows true polymorfisim

[The Ghost In The Machine]

In comp.lang.java.advocacy, Tor Iver Wilhelmsen
<jadedgamer at hotmail.com>
 wrote
on 31 Aug 2006 18:31:15 +0200
<uzmdklve4.fsf at hotmail.com>:
> The Ghost In The Machine <ewill at sirius.tg00suus7038.net> writes:
>
>> Also, one language is very conspicuous by its absence: C#.
>
> He does not date any of the updates, so it's unclear how recently it
> has been updated (a lot of the web is stale, like a rotting tree in a
> forest.)

Aye; my webpage has a similar problem. :-)

>
>> AmigaBasic -- Microsoft-sponsored Amiga variant
>
> Well, at the time Microsoft were the makers of the de-facto BASIC
> implementations - M-BASIC for CP/M, the various variants in VC-20 and
> C-64 and later derivates of those, and many other home computers.
> "Sponsored" should probably be "created" instead - I assume they were
> paid for the job.

OK, "created" then. :-)


>
>> Also, Java now has templates. (The implementation is pretty gross
>> and has some quirks, IMO, but it's better than nothing.) C++ has a
>> typing system ("type_of" or some such; I'd have to look) which
>> yields little more than the mangled type name and static inheritance
>> testing capabilities. Of course C++ doesn't have dynamic inheritance
>> anyway.
>
> There's the virtual stuff, and you could conceivably implement dynamic
> inheritance via the bare-bones C layer - like function pointers. The
> type information in C++ (RTTI) is optional.

Oh yeah, that's true.  Still not all that dynamic, though, unless
one recompiles.

>
>> Dynamic type creation. I don't know if Java has this or not. One can
>> of course attempt bytecode synthesis -- I think that's what BCEL
>> uses -- but that's a bit of a hack.
>
>     Groovy could possibly be used for that; also IIRC Java 6 adds some
> features for that. I seem to recall security implications being one
> reason this ability wasn't included from the start.

Not familiar with Groovy; I'll have to look into that.
It's amazing what's out there; one of the problems with
Free Open Source Software (FOSS) is that there's multiple
choices for the obvious stuff. :-)

>
>> Dynamic method creation. Java does *not* have this. AIUI
>> Smalltalk-80 does; one can take an existing class and add methods
>> thereto.
>
> Yes, but that's because a Smalltalk program lives inside a big binary
> "image" that is mutable. Woe unto you if that big binary file gets
> corrupted.

Indeed.

I for one would want Smalltalk to have the ability to
transcript certain messages but would have to look.
(One might call that an edit audit trail.)

>
>> Dynamic method deletion. I for one might only want this in the
>> context of a "sandbox" but if one can create methods, one should be
>> able to delete them as well if only because of undo.
>
> The problem with deleting a method is whether the runtime can handle
> it: Smalltalk has doesNotUnderstand:#aMessage, Java has
> NoSuchMetohdError - what does C++ do? A zeroed virtual method would
> cause a pure virtual method call error, which I guess C++ programmers
> are trained to take into account.

I'd frankly have to look.  My thinking is that it's a message followed
by an exit().

> Also, if class A has a method and
> you delet it in subclass B, it breaks the Liskov Substitution
> Principle, there B should be able to function where an A is wanted.

Heh...an interesting name; I'm not familiar with that
issue.  Of course it's important for B to be an A in
many cases, though AFAICT usually what happens is that
A declares a method virtual with an implementation and B
munges it.

>
>> Dynamic method rename. This could lead to much madness but this
>> might be useful during sandboxing.
>
> A method's name and its "address" are distinct, but for dynamic method
> dispatch, what about any other code that doesn't know the new name but
> assumes the method is called the same?

What indeed?  Much madness.

>
>> Dynamic inheritance. For those languages that support inheritance
>> one might liken it to changing what the language inherits or
>> implements on the fly. I don't know of any language apart from
>> Smalltalk that can even think about allowing dynamic inheritance,
>> but it's a thought.
>
> If you can change a Perl class, er, module's @INC array I think that
> would support it.
>
>> Operator overload (e.g., C++'s operator ==()).
>
> Or rather "dotless/prefix method invocation with the added baggage of
> precedence rules". Smalltalk solves this by 1) not having those
> precedence rules, 2) have dotless method invocation and 3)

...?

I'll admit Smalltalk has a lot of things, but popularity isn't
unfortunately one of them. :-/

>
>> 
>> Name overload. C does not have it; C++ and Java do. I suspect Ruby
>> and Python do as well.
>
> Are you referring to namespaces, ie. namespace isolation?

Hmm...that could use clarification.  The general idea is that
Java and C++ allow

void routine1(const char *);
void routine1(int);
void routine1(double);

in the same module or class.

I suppose a slightly better term would be "function overloading", since
that's what it was called some time back.

C does not have this capability, and it occasionally leads to problems
if a program doesn't use proper design methods (such as declaring all
methods in .h files and including them, as opposed to putting local
extern signatures in the .C code -- yes, my prior employer had code
that did exactly that for awhile; hopefully it's cleaned up by now since
it's been almost 6 years :-) ).

>
>> Globals. Java has no globals as such, unless one counts class names.
>> C is all globals, unless one counts statics.
>
> Even the fully qualified classes are only "global" in the context of a
> classloader and whatever classloaders it delegates to.

Good point.

>
>> Unnamed classes. new Runnable() { public void run() {...} } is
>> Java's contribution. Can be useful.
>
> Well, they do end up with a name after compilation.

Picky, picky.  :-) In any event the name is not available
to the program source; one can't expect to do things like

Runnable$1 r = new Runnable() { public void run() {...} }

and hope for it to work.  One might be able to do something
slightly silly like

Class c = Class.forName("Runnable$1");

c.newInstance();

but for Java that's slightly problematic, especially if there's
more than one Runnable in that class.

> And you do not
> want to open that can of worms since then you end up with Ruby and
> Smalltalk users dragging out closures and C# and Lisp users dragging
> out lambdas... :)

Yes, well AFAICT a closure is some code with a little context; in Java
some of the context is required to have final variables, or a method by
which it can pick up its owning class's members or call its routines.

>
>> Nested classes.
>
> Generally that's just a namespace issue. In Java, a class Fie nested
> inside Foo is the top-level class Foo$Fie with some compiler magic to
> ensure it's used correctly, which leads to funny stuff like
>
> Foo.Fie object = new Foo().new Fie();
>
> which gets turned into the bytecode equivalent of
>
> Foo$Fie object = new Foo$Fie(new Foo());

Hm.

>
>> Primitive types -- in other words, the int<->Integer dichotomy we
>> all know and love in Java; such also exists in C++ and IINM C#. I'm
>> not sure if Smalltalk has such a concept, or not; Smalltalk allows
>> overrides on numbers. (In Java one might contemplate 2.toString(),
>> for example!)
>
> In Smalltalk you ask the 1 object to count to 10 for a loop. It makes
> sense there, it would not feel "right" in the C family...

Or anywhere else that I know of offhand.

>
>> Arbitrary integer size. The only language I know having this is
>> Common LISP.
>
> java.math.BigInteger, but the operations you can perform are limited.

Hm.  OK, "arbitrary number size with transparency".

>
>> Thread-level variable/value scoping. In Java this is done using the
>> ThreadLocal class, but is not (AFAICT) supported by the language
>> proper.
>
> Yes, and that leads to a problem where if you forget to null a
> ThreadLocal you can "leak" objects.

Ugh.

Well, unfortunately for Java it's all too easy to
leak certain objects, though the only one coming to
mind are FileInputStream, FileOutputStream, FileReader,
and FileWriter.  Forget to close them before the variable
goes out of scope and they remain open forever, as far as
I can tell.

(Maybe that'll be fixed in a subsequent rev.  I don't know.)

>
>> One might even contemplate function-level scoping, but that would
>> only be useful if one can create new functions on the fly and modify
>> these values; otherwise, they might as well be static.
>
> As long as you make sure you never use a private static member
> elsewhere than in that particular method, it can play the role of a
> function-level method.
>
>> Persistability. In Java one can implement Serializable or
>> Externalizable, and generate output from an object. I've always
>> considered this a bit of a weird hack but it can come in handy, and
>> forms one leg of the Java EJB implementation.
>
> Persistability is left as an excercise to libraries in most languages.

True, and in that library one usually has a base class.

>
>> Volatile field. In Java there is a volatile keyword. I don't know
>> its precise semantics but it applies to fields.
>
> In Java it's generally a hint to the optimizer NOT to optimize away or
> make any assumptions about access to a field.
>
>> C#'s event handling emulates this concept to some extent using the
>> += operator, though I doubt they do it all that generally -- or all
>> that well.
>
> Well it's closer to a list of function pointers, sorry delegates; not
> much more than Java's more explicit (or cumbersome if you like) event
> interfaces can do.

Operator overloading has two issues: it's far more convenient to
write something like

Matrix m1, m2;

Matrix m3 = m1 * m2;

instead of

Matrix m3 = m1.multiplyBy(m2);

or

Matrix m3 = Matrix.multiply(m1, m2);

but it's harder for the compiler and the user to parse.
So it's a tradeoff.

The main problem I have with Swing event handling is
that occasionally it's not clear when I have to tell the
listeners that I've done something to a class which manages
a bunch of listeners.  Also, ideally, one would not need
to fire off the listeners in sequence -- though without
explicitly spawning subthreads that would be difficult
in Java.

The main problem with C# event handling is that I don't
know its ramifications, but I consider delegates a bit silly,
mostly because of the Java++ fiasco.  That was not COOL,
Microsoft. :-)

>
>> Integrated database access (and how tightly). C++ has none at all,
>> though of one can use various third-party libraries. Java has some
>> base-level API -- the java.sql.* and javax.sql* library.
>
> Well, those are general library APIs that require native or
> socket-based implementation by vendors or third parties.
>
> What you talk about is better represented by "inline" SQL in the form
> of SQLJ or Oracle's Pro*C and related products.

There's the issue of how to handle schema changes, as well; that's
probably why nobody wants to tightly integrate anymore.  I can't really
blame 'em.

>
> It boils down to how much should be in the language (syntax, compiler,
> runtime) and how much should be left to libraries. E.g. he has a "no"
> for garbage collection in C++, but there are libraries for that sort
> of thing (relying mostly on the ability to override the new, delete
> and assignment operators. Even in Java you often have a choice of
> garbage collector algorithms in a runtime.

Hm; I'll have to research that.  Apart from the aforementioned stream
issues and the occasional "oops I left the thing in the global
Collection" issue, though, I've not had to do much with garbage
collection, though I did write a rather poorly-performing cache.

I will definitely have to fiddle with WeakReference at some point,
though it's probably easier just to punt to a solution like
Hibernate or JBossCache (TreeCache) or even Castor/JDO.

Like I said, FOSS has a lot of stuff out there; the main problem
for me is finding it. :-)

-- 
#191, ewill3 at earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.