Umm, just a point here -- we don't *necessarily* need named objects,
although they are one way to work. Another possibility, with some real
merit, runs as follows:
We add a new node, called something like "behaviour". This specifies
the behaviour code for the current object (and yes, we need to somehow
clarify what the "object" is). The behaviour code works in a strictly
object-oriented way, and knows that it applies to "this" object.
Since the object is pointing to the behaviour, and the behaviour
picks up the object as a sort of back-pointer, it doesn't need a
name in order to access the object.
We might need naming of some sort to make object interactions work,
but even there I'm not sure -- if interactions were described in a
message-passing class-to-class manner, object names might just prove
redundant; class names would be more important.
Which isn't to say that names are a bad idea or anything; I'm just
not sure that they are necessary as the above makes them sound...
-- Justin
Who is slowly warming to the idea that we
should really be using object-oriented
paradigms here in many cases...
Random Quote du Jour:
"Why is it that many folks find a malleable, very human document like
the Society's Corpora, that was formed by the anvil and tongs of
vigorous debate, and want to turn it into dead words engraved in marble?"
-- Bertram of Bearington