How to inject methods

chromatic chromatic at
Mon Jun 28 21:15:39 UTC 2010

On Monday 28 June 2010 at 13:30, Andrew Whitworth wrote:

> > Then don't store methods in NameSpaces.
> Too late. It accidentally just happened that way several years ago.

TT #389 is part of a strategy to fix that.

> 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.

This is *exactly* the motivation for *never* storing methods in NameSpaces.

> So we're not allowed to fix the problems we have before we are forced
> to completely rearchitect the entire object model?

Fixing the object model *requires* fixing these problems.  Papering over them 
with workarounds perpetuates the damage and delays improvements.

Parrot *cannot* support Perl 6 semantics with the current object system.  Full 
stop.  If we want Rakudo to run efficiently on Parrot and if we want Rakudo to 
interoperate with other languages on Parrot, we have to fix the object system.

Parrot's conflation of NameSpace and Class requires the clunky initialization 
system with :load and :init to attempt to create Class instances before 
runtime.  This is fragile and depends on subtle issues of ordering.

A *declarative* PIR syntax for Classes, attributes, and methods would not 
require this fragility, because we could set up the Classes at *compilation* 
time and freeze them into bytecode.  (Note that the declarative PIR syntax for 
HLLs and NameSpaces and subs avoids these problems.)

> 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.

You have that ability.

> I do not want to define a class to hold my method, that's extremely
> unnecessary and counter-intuitive.

Then I suggest you write your own C extension external to Parrot's core, 
because Parrot's new object system will never store methods in NameSpaces.

-- c

More information about the parrot-dev mailing list