How to inject methods
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
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
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.
More information about the parrot-dev