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