How to inject methods
wknight8111 at gmail.com
Mon Jun 28 21:50:15 UTC 2010
On Mon, Jun 28, 2010 at 5:15 PM, chromatic <chromatic at wgz.org> wrote:
> This is *exactly* the motivation for *never* storing methods in NameSpaces.
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? 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")?
> Fixing the object model *requires* fixing these problems. Papering over them
> with workarounds perpetuates the damage and delays improvements.
I don't see how that would delay improvements. The single biggest
delay is the deprecation policy, and that explicitly provides a
mechanism to make this papering temporary: We mark anything we add for
2.6.0 as experimental and remove those things as soon as a better
system is in place. 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.
The reality is that there are several projects in the Parrot ecosystem
broken or seriously delayed because of the TT #389 changes. I would
like to work around those changes, get things building again and get
development back on course. Functionality was removed in TT #389, and
until the new system gets put into place there is currently no way to
access that functionality in a reasonable way.
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?
> 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.
Good. Very good. One problem though: Parrot isn't currently using the
new object system. We're still saddled with the same shitty, buggy,
old object system. I am completely in favor of designing and
implementing a new object system that will avoid all these problems,
and I will personally devote as much time as I am able to see that it
is implemented quickly and properly.
That said, We can't expect other projects in our ecosystem to sit and
wait for the magical wonderful future where Parrot doesn't have the
problems it has now. If we need to paper over some of the shit now so
we can things moving again, I think we should do that.
More information about the parrot-dev