Duck typing alows true polymorfisim

[Tor Iver Wilhelmsen]

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.)

> 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.

> 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.

> 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.

> 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.

> 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. 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.

> 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?

> 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)

> 
> 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?

> 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.

> Unnamed classes. new Runnable() { public void run() {...} } is
> Java's contribution. Can be useful.

Well, they do end up with a name after compilation. 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... :)

> 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());

> 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...

> Arbitrary integer size. The only language I know having this is
> Common LISP.

java.math.BigInteger, but the operations you can perform are limited.

> 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.

> 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.

> 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.

> 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.

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.