Date: Tue, 2 Mar 2004 21:29:21 -0800
From: [log in to unmask]
...
So, if you had a function-like syntax to reference components, ...
I have no idea what the OO extensions in F2003 are going to look like,
apologies in advance, but I'm guessing they are similar to the message
sending model of C++ and Java:
C++: objectRef.methodName(args...)
or objectPtr->methodName(args...)
java: object.methodName(args)
This is certainly the simplest, as it allows the object to have a
"virtual function table" and the appropriate implementation of the
method is extracted from the table. Lisp Machine Lisp started out
this way
(send object ':messageName ...args...)
but CommonLisp bit the bullet (mid '80s, don't know how far back the
ideas date) and turned things back into functions. Generic functions.
With polymorphic dispatch:
(draw graphic device)
where the draw method is selected based on the runtime types of BOTH
the graphic and the device. Note that C++/Java overloading only
selects methods based on the *compile-time* type of the arguments, so
generic functions are different.
(Yes, they are generally a bit slower because the virtual function
table lives in the method's datastructure, not an object's, plus the
runtime time to determine the multi-method. C++'s semantics allow
message sending to be a compile-time index into the virtual function
table; quite fast. Java's semantics require runtime lookup; hashing
and caching speed this up. As I recall from the Symbolics
implementation, there are ways to design cascading hash-like tables to
make it "sufficiently" fast.)
So... in addition to function-like syntax to reference components, use
function-like syntax to invoke OO methods. The same abstraction
arguments apply.
