HaloO,
Stevan Little wrote:
Now, as for class methods, I suppose it is possible to just stash then
in the classes symbol table like with variables. However, do we then
loose the method call syntax?
I think not. But the current notion seems to drift closer to my
idea of "free methods" versus "slot calls". To express that in therms
of your initial equation
object == state + behavior
would be expressed on the first meta level as
class == data(structure) + code(structure)
which means that the compiler syntactically splits the class
definition into an active and a passive part. Call this symmetry
breaking if you like. The same asymmetry exist in the method call
syntax
$foo .action;
because the compiler compiles that into a lookup of 'action' from
the method part of the MIR (Meta Information Repository, World in Russian)
followed by a dispatch on the actual runtime type referred to by $foo.
In other words, the name that connects the compile and runtime is 'action'.
If this name shall be retrieved from the instance at runtime without going
through the method dispatcher I have proposed to wrap-up the name as
$foo :action;
Without the $ sigil a bare foo is interpreted as a name lookup in the code
part of the MIR which is the union of all subs and methods---subs beeing
nullary methods so to speak. That gives
foo .action; # dispatch action on retval of foo
and
foo :action; # bind named param in the call to foo.
These two things are on the tightest precedence level, which in my eyes
makes . and : meta sigils or some such.
We could actually combine these with the idea of the current name beeing
a sigilled underscore and '_._' denoting the current method on the current
topic, and '_:_' the current key from the current topic :)
Hmm, these would make {_} the closure of the current continuation or so.
This also means that they would not
(directly) be inheritable since inheritence moves along superclass
lines, and not with @ISA. I am also not sure what you mean about
multi-methods either, could you please explain more?
Symmetric MMD at least has the meaning that the above mentioned asymmetry
doesn't exist for infix ops on the syntactic level:
$x foo $y;
which neither means
($x foo) $y; # calculated prefix op from postfix foo
nor
$x (foo $y); # calculated postfix op from prefix foo.
I can't speak for metric MMD, though. But IIRC, the metric is
'sum of superclass hops'.
--
