another idle thought:
in many traditional OO languages, classes/objects necessarily 'contain' the
methods (in terms of both their definition syntax and conceptualization).
what about being able to define operations "over" a class if need-be (sort
of like operator overloading, but with methods)?...
there are various ways this could be done in a language (depending on
existing syntax and semantics).
in my VM framework, similar is already done fairly regularly, and similar
notions already exist within many functional languages, as well, C# allows
something vaguely similar via partial classes, ...
also notable is that in the class/instance/interface model, there are
different ways to make use of the concept of an interface:
one is the more strict and traditional Java sense, where a class implements
an interface, and can be cast to said interface (the implementation will
throw an exception if the class doesn't implement the interface);
also possible is to retroactively bind an interface to a class, effectively
using the interface as a "window" into other aspects of the object, and
possibly stuffing new fields or methods into an existing class (the usual
term for this being "interface injection" in the JVM).
both are somewhat different ways of regarding interface, yet both are
generally treated as the same concept.
in my VM / framework, the latter is actually fairly easy and cheap, since I
don't actually use vtables to associate interface methods to classes: it is
actually done with a big hash table, where the (precomputed) class-hash and
method-hash are combined and used to look up the method in this big hash
table (in fact, the core OO machinery doesn't even really care whether or
not an object implements an interface, since it will work either way,
however a language may choose to verify that a class implements an
interface).
given both experience and benchmarks, I am not really even sure one needs to
bother with vtables for virtual-method dispatch, as it would allow a simpler
implementation just to use a big-ass hash table for all method dispatch
(although it would add a little cost over vtables + frozen object layouts
with dynamically-generated-thunks, but oh well...).
I have often used similar to implement prototype objects as well (just it is
hashing object and field/method, rather than class and field/method). the
class/instance OO system also supports prototype objects, partly reusing the
same mechanism as the interface mechanism, and also uses it to fake
multiple-inheritence as well (generally unused though, and does not
implement proper C++/Ada/... semantics).
(technically, fields can also work via interfaces...).
grr... I somewhat lost track of the original point...
----- Original Message -----
From: "Steve Dekorte" <[email protected]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Thursday, October 14, 2010 3:17 PM
Subject: Re: [fonc] On inventing the computing microscope/telescope for
thedynamic semantic web
Amen.
On 2010-10-08 Fri, at 07:57 PM, Casey Ransberger wrote:
I think "type" is a foundationaly bad idea. What matters is that the
object in question can respond intelligently to the message you're passing
it... Asking for an object's class.... reduces the power of polymorphism
in your program.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
