On 2/12/06, Thomas Sandlass <[EMAIL PROTECTED]> wrote:
> > > IIRC, you can always create a new method for a class, even outside of
> > > its definition, simply by ensuring that the first parameter to be
> > > passed in will be an object of that type:
> > >
> > > method bark (Dog $_) { ... }
> >
> > I don't think this is true unless it is a multi method, in which case
> > it is not actually a method of the of the class, but instead just
> > DWIMs because of MMD and the fact we allow an invocant calling style
> > freely.
>
> Yes, the question of ownership of methods is still
> somewhat unresolved. I think we need to distinguish
> something I've called slots in an object from free
> (multi) methods that are defined outside of the class
> definition block. BTW, do the outsiders have access
> to the private data slots with the $! twigil?
I think that multimethods defined outside of the scope of the class
should not have access to the classes data slots, it should use the
accessors. And those multimethods should live in the package in which
they are defined. The class implementation can stash refs to
multimethods which apply to it for optimization reasons, but this has
nothing to do with the language design itself.
As far as method name disambiguation, we should use the calling style
(invocant vs. normal function call) to determine which method to call.
I am sure there are other edge cases to be uncovered here as well, but
I can't think of them at the moment.
Stevan
