How to inject methods
chromatic at wgz.org
Mon Jun 28 19:11:45 UTC 2010
On Monday 28 June 2010 at 11:42, Andrew Whitworth wrote:
> The NameSpace PMC contains several sets of things: It contains a set of
> globals, a set of methods, etc.
4) You create a method and you store it in a NameSpace without an associated
class. What happens? Why?
5) You create an anonymous class or role. Must you create a NameSpace in
which to store methods? Why?
> We can access the set of globals from PIR, we cannot
> really access the set of methods from there. Even if it was a
> read-only set (after PBC load time, of course), we should still have
> access because the data is still there and there are legitimate uses
> for it.
Which legitimate uses? "I want to look up methods stored in a NameSpace
because methods can be stored in a NameSpace" is question begging.
> But beyond that, there's a fundamental difference between what a Class
> does, and what a NameSpace does.
... which is precisely the reason *not* to store methods in a NameSpace.
> The NameSpace really has more of
> a relationship with PBC than anything, and the list of "methods" in
> the NameSpace generally represents the methods that have been
> explicitly defined in PBC as being part of that namespace.
Don't confuse the inadequacies of PIR/PASM syntax to express object concepts
effectively with the desirable semantics of Parrot's object system.
> The namespace is where methods get defined. Then they are moved to the
> Class where they are included in a lookup hierarchy.
That poor bad design is an artifact of a poor metaobject system, the
inadequacies of PIR syntax, and the original object design lifted straight
from Perl 5 without much thought as to how a good object system should work.
I maintain three modules on the CPAN which work around the damage of "A method
is just a function stuffed in a namespace!"
> A lot of semantics would need to be fixed or redesigned if we wanted
> the ability to store a method Sub in the namespace as a data item like
> any other PMC can be stored there. I think we will want that ability
> eventually, so that we have clear and consistent namespace storage
> semantics. We certainly don't support it now.
What value is there to storing a method in a NameSpace? How do you invoke it?
(If you can't invoke it, what good is it?) What do you do with it?
If you *can* invoke it, consider that now there are two dispatch mechanisms
and two reflection systems, or at least two places that dispatch and reflection
must look to work correctly. See default's find_method for one fun example.
If you want to define methods on core PMCs, see also default's find_method as
well as the entirety of PMCProxy to see how the current system works around
(badly) the heteromorphism of core PMCs and objects.
> Classes and NameSpaces are different, I
> want to use each in different ways and not try to force one to fill in
> for behaviors that the other is missing.
Then don't store methods in NameSpaces.
More information about the parrot-dev