Duck typing alows true polymorfisim

[The Ghost In The Machine]

In comp.lang.java.advocacy, Jeroen Wenting
<jwenting>
 wrote
on Wed, 30 Aug 2006 20:18:52 +0200
<12fblk87ppk7ief at corp.supernews.com>:
>
> "Simon Forman" <rogue_pedro at yahoo.com> wrote in message 
> news:1156533807.630662.12330 at i42g2000cwa.googlegroups.com...
>> atbusbook at aol.com wrote:
>>> lets say you want a generic numerical algorithom like sum
>>>
>
>> What's your question?  (Or, if no question, point?) :-)
>>
> Reads like the weekly "Ruby is better than Java because XXXXX" post. 
>

Well, FWIW one could throw this into the pot and watch it explode:

http://www.approximity.com/ruby/Comparison_rb_st_m_java.html

:-)

This table needs some work.  The leftmost column is
unidentified, for example ("Capability" or "Feature"
suggests itself here) and each of these capabilities or
features should probably have a link to a short description
of the capability or feature, preferably with an example.

Also, one language is very conspicuous by its absence: C#.
One could also add C, Basic, and ISO Pascal; the first is
widely used but lacks polymorphism, inheritance, dynamic
casting, etc., and the last is probably not used anywhere
in its form (though dialects are plenty), since one can't
do anything *with* it, really -- though IIRC someone has
told me it can at least open an arbitrary file now, as
opposed to having the user pass one down in the program
identifier list. :-)

As for the middle one: which dialect?  Was it ever
standardized?  Visual Basic is a very object-oriented
language in spots, but it's not the only variant; I
used to use at least 4 other variants off and on:

GWBasic -- old IBM PCs
ABasic -- Amiga variant
AmigaBasic -- Microsoft-sponsored Amiga variant
HP Basic (?) -- load tape into very old HP 21xx-series
computer and one had a multitasking Basic which could
do the simpler stuff, but its error diagnostics were
pure numeric: ERROR 67 IN LINE 20.  Fortunately, we
had plenty of pamphlets detailing the errors.

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.

One could include additional capabilities:

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.

Dynamic method creation.  Java does *not* have this.  AIUI
Smalltalk-80 does; one can take an existing class and add
methods thereto.

Dynamic method override.  This may be an artificial distinction
but in some languages -- Smalltalk-80 again, presumably -- one
can take an existing method implementation and override it in
the same class, but without allowing the creation of new methods.
How this would be enforced without additional keywords and/or
a full-fledged ACL method/metadata system, I for one do not know.

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.

Dynamic method rename.  This could lead to much madness
but this might be useful during sandboxing.

Dynamic method signature changing.  Eclipse has a
reasonable way of doing it using source but I'll admit to
wondering whether it makes sense given a Method descriptor
whether one should be able to edit (as opposed to viewing
or invoking) that descriptor, and when.  One might implement
this as a new method, followed by a delete of the old one.

Dynamic other method deletion.  If one can delete one's own
methods in an edit session, should it be possible to delete
others' methods too?  An interesting question.

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.

Operator overload (e.g., C++'s operator ==()).

Name overload.  C does not have it; C++ and Java do.  I suspect
Ruby and Python do as well.

Globals.  Java has no globals as such, unless one counts
class names.  C is all globals, unless one counts statics.

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

Nested classes.

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

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

Explicit module-level identifier scoping.  In C++ this
might be implemented during link using the -E flag on ld,
for example (there is the Microsoft concept of exporting
in their DLLs, which is vaguely similar as well).
An identifier could be "global" in the module but
inaccessible to those outside of the module.  Modules
can include other modules in C++, which makes life
even more interesting.  (This might be more of an
environmental versus a language issue.)

Thread-level variable/value scoping.  In Java this is done
using the ThreadLocal class, but is not (AFAICT) supported
by the language proper.  This of course differs from
call-level (stack), global-level, and class-level scoping.
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.

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.

Transient field.  In Java a capability exists to mark a
field as transient, which is a hint during serialization
that this field in a class not be persisted.  (One can
check for this using the Modifier.TRANSIENT bit.)

Volatile field.  In Java there is a volatile keyword.  I
don't know its precise semantics but it applies to fields.

Virtuals.  In C++ one must explicitly declare a function
virtual; C has none at all, and in Java one must explicitly
declare a function final (disallowing overrides) and cannot
really disable a non-method's "virtuality" at all.

Pure/abstract virtuals.  C++ has the "=0" construct; Java
has the abstract keyword.

Static virtuals.

Delegates.  This Microsoftish concept is a bit hard for me
to pin down (it feels a lot like a C++ method pointer --
or even a C function pointer) but is occasionally touted
as an advantage for such languages as C++ and the ill-fated
Java++, which had them as part of the language.

First-level object functions.  AIUI, this is a high-level
concept which would allow for constructs in a hypothetical
language such as

k = (f @ g)(s1,s2,s3);

if f has arguments (int v) and g has arguments (string s1, string s2,
string s3).  It would also allow for constructs such as

h = f @ g;

where h is a "function variable" of some sort -- and it would have
the same signature as g.  (The '@' is used in lieu of 'o', although
one might use character U+2218 (ring operator) in a theoretical
language where everyone understands Unicode.)

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.

Function-function operators.  Under certain conditions the
construct f + g makes sense, if they have compatible signatures;
one might even write

int (f + g)(int a)
{
    return f(a) + g(a)
}

Ditto for f - g, f * g, and even f += g if f returns a reference.
One can also contemplate unary operators such as '-f' .

Set/collection union/intersection/subtraction/element
of support.  This is probably most useful for hard-core
mathematicians and database junkies. :-)  In Java one
might declare a Union class easily enough, which takes
two collections and tries to do something intelligent with
them during a scan with the iterator, and of course
the .contains() method is good enough for now.

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.  I suspect C#'s access is similar;
I don't know regarding Ruby.  A variant of COBOL was
able to access the database -- DEC's DBMS product,
which was a CODASIL affair -- by using statements in
the language itself.  Nowadays, apparently, such are
considered slightly problematic, mostly because DB defs
change a little too often.

Arbitrary iterator positioning.  In C++ some collections
can position an iterator in an arbitrary location within
the collection -- the only obvious one would be arrays.
The closest one might get in current Java is to do a
head(), tail(), or subset() and iterate over that.

GUI support -- this is primarily API/library but might
be put in the language if it makes sense -- perhaps when
combined with collections and sets (e.g., is a point
within a rectangle?), though there are some issues such
as whether one would want to enumerate all the elements
in a collection (points in a rectangle).

There's probably a number I've missed but there are
some interesting and somewhat unexplored directions in Java.
Whether it makes sense to explore them is not clear to me.

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