How to inject methods
wknight8111 at gmail.com
Mon Jun 28 20:30:35 UTC 2010
On Mon, Jun 28, 2010 at 3:11 PM, chromatic <chromatic at wgz.org> wrote:
> 4) You create a method and you store it in a NameSpace without an associated
> class. What happens? Why?
IMCC creates methods and stores them in the namespace all the time.
Classes are created lazily, so this is the case dozens of times at
Parrot startup, at least. What happens now and why?
Again, It's not that I want to do anything new with this mechanism, I
simply want read-access to the methods that are already stored in the
> 5) You create an anonymous class or role. Must you create a NameSpace in
> which to store methods? Why?
I don't know. That's outside the scope of what I want. Recap:
1) I write PIR code
2) in my code I have various .namespace directives and .subs with :method.
3) These subs are entered into the namespace, since the class doesn't exist yet.
4) I want to access this exact list of methods, which I know for a
fact is stored in the namespace
Anything else, including things involved in the interactions between
classes and namespaces, or things that are changed at runtime, are not
really a huge concern of mine. We don't even have a way to read the
list of methods in the namespace currently, I don't think we need to
worry about editing that list quite yet.
> Which legitimate uses? "I want to look up methods stored in a NameSpace
> because methods can be stored in a NameSpace" is question begging.
I briefly gave my reasons in the first email. I want the ability to
write a method (with the all-important "self" keyword, so IMCC
requires the :method identifier) and to inject that method into a
target class at runtime. These methods need to be sorted by namespace
for sanity and cleanliness. I do not want to define a class to hold my
method, that's extremely unnecessary and counter-intuitive. I do not
want people to try and instantiate an object of a "class" which I have
not and do not want to define.
And let's not presuppose that nobody else wants this functionality, or
that there are no other reasons besides this one that is driving me
right now. The TT #389 fix is not so old that all possible effects of
it have been discovered, analyzed, worked around, and resolved.
>> 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.
Well, that's a separate issue entirely, though I'm not sure I see any
reason around that. NameSpaces really serve several different
purposes, and I'm actually pretty certain that these functions should
be divided into multiple types (storage of runtime globals,
organization of named functions to prevent collisions, storage of
compile-time information needed to instantiate things like Classes,
In fact, I would far prefer if these functions were separated out into
> Don't confuse the inadequacies of PIR/PASM syntax to express object concepts
> effectively with the desirable semantics of Parrot's object system.
And don't confuse short-term workarounds for recent problems with some
sort of over-arching design decision about parrot's object model. We
used to have access to the methods in the namespace, and some things
did rely on that behavior. It's gone now, and I need a replacement
mechanism to get that same information. The methods themselves haven't
actually gone anywhere, but they can no longer be accessed through the
same interface (and no replacement interface was provided, which is
what I need).
> 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.
So we're not allowed to fix the problems we have before we are forced
to completely rearchitect the entire object model?
> I maintain three modules on the CPAN which work around the damage of "A method
> is just a function stuffed in a namespace!"
You're really misconstruing what I want. Methods are "in" the
namespace, but are kept separate and distinct from other data there
(for good reason) and can be made available through a separate,
special-purpose interface. I don't want methods comingled in a
namespace with other data items. I don't want to treat them like
anything in the namespace. All I want is to add a secondary interface
that I can retrieve the data when I need it. Nobody else has to ever
use it or even be aware of it.
> 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?
Rephrase to "what value is there to storing any arbitrary object in a
NameSpace". You invoke it by doing a get_x_global, and then invoking
the resultant PMC if you desire. We can store things in the namepace
as "globals", silently doing something weird with the variable because
it's a slightly different type is bad design all the way around.
> 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.
Don't want that. You're still trying to conflate the idea of a class
and a namespace. The namespace holds "global" variables which should
be able to be any arbitrary type (they can't be right now, as I
mentioned above, but they *should* be in an ideal future parrot).
If I store an Integer "Foo" into a Namespace with set_root_global, it
doesn't force objects from that class to suddenly have a field Foo.
Likewise, if I set_root_global a Sub PMC into a namespace, it
shouldn't force the poor object to now have a new method. If you want
to add a method to the Class, you add the method to the Class.
> Then don't store methods in NameSpaces.
Too late. It accidentally just happened that way several years ago.
More information about the parrot-dev