For the same reason we have set_attr, set_attr_str, get_attr, and get_attr_str, even though they're only used by ParrotObject - it allows for multiple, concurrent object systems. This goal is mentioned in PDD 15, in "What The Bytecode Sees". Why tie programmers into the default way of doing things? In Smalltalk, objects and classes work very differently, to the point where I have a wrapper object around every class. It would be a whole lot easier if I could define my own class implementation.
On 3/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm (via RT) wrote: > > This patch adds the add_attr, rem_attr, and rem_attr_str vtable > methods. These will come in handy for Ruby's metaclasses or > Smalltalk's class objects. The only PMC currently affected by this is > ParrotClass, and the rem_attr and rem_attr_str methods are still > unimplemented. It's more of a design question than a code question. Why make add_attr, rem_attr, and rem_attr_str vtable methods rather than simply methods on the Class class (the metaclass)? They only affect ParrotClass, which means we're defining vtable entries for functionality that will be used by one PMC type. Allison
