How to inject methods

chromatic chromatic at wgz.org
Mon Jun 28 22:04:11 UTC 2010


On Monday 28 June 2010 at 14:50, Andrew Whitworth wrote:

> While tangential, I definitely think this is a point worth exploring.
> Are you saying that we shouldn't be storing any data items in
> NameSpaces, or just the special case of Subs that are flagged as
> methods?

My point is that methods are attributes of Classes in the same way that object 
properties are attributes of Classes.

> In the context of the get/set_x_global opcodes, should
> library developers and HLL developers need to be aware that behavior
> is different between an Integer and Sub, or an Object that overrides
> VTABLE_invoke (without necessarily needing to "does invokable")?

I don't understand what that has to do with methods.  I consider anything else 
that we might store in a NameSpace outside of the scope of this discussion.

> The second largest delay is the complete lack of
> anything like a design for Parrot's hypothetical, ideal, future object
> model. Somebody come up with a really good comprehensive plan, and I
> can put away the paper.

This is my 2.9 priority.
 
> I'm all for better design, but we have a supported release on the
> horizon, broken projects laying in pieces around our feet, the
> "experimental" tag that we can employ to keep us from making
> earth-shattering mistakes....so what's the hangup, exactly?

We marked the changes for TT #389 explicitly in our deprecation policy.  I 
believe the description read something like "We no longer store methods in 
NameSpaces."  (Debates over the efficacy of our deprecation policy are another 
thread.)

Knowingly adding a new feature--immediately deprecated--to which people will 
have to migrate their code and then from which they will have to migrate their 
code at the next deprecation point seems like a lot of busy work to me.

-- c


More information about the parrot-dev mailing list