Hi,
When implementing prototype OO, the HOW for objects with different
behaviours will be shared. This issue is not new, but before we thought
that it would be possible to solve that by forcing $foo.HOW to be a
proxy object that would rewrite the call putting $foo as the invocant.
Me and nothingmuch, during PPW in Braga, got more into that issue, and
we came to the realisation that this is not really possible, as it might
be actually desirable to have a real meta object, storing
meta-information that would be part of that metaobject implementation.
The HOW might be implementing some kind of RPC, for instance, and that
way, it might need to store some meta-meta-information, like the address
of the RPC endpoint. This makes the idea of the proxy object inviable
because the user might need to talk to the HOW as a real object.
That way,
$foo.^can('bar') cannot be the same as $foo.HOW.can('bar'), because the
first has both $foo and $foo.HOW implied, while, in the last, $foo
cannot be taken from anywhere.
Therefore I suggest making $foo.^method format the only way to get
metamethods related to this object, while $foo.HOW would have a
behaviour which would be implementation dependent (at least until it's
standartized)
SMOP will have $foo.^can('bar') actually translated to
$foo.HOW.can($foo, 'bar'), which will keep $foo.HOW as the invocant, and
prepend the referring object as the first positional argument (following
the example of the sub-dispatch fallback).
In that case, we might either:
1) remove all references of $foo.HOW.can('bar') and say that this is
implementation specific (since Class-based OO can implement it that way)
2) Assume the capture-translation and define that
$foo.HOW.can($foo,'bar') keeps the $how as the invocant and must receive
the referring object as first argument.
daniel
