On Mon, Jun 28, 2010 at 5:15 PM, chromatic <[email protected]> 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. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
