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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
