Oli <[EMAIL PROTECTED]> wrote:
But, even if we stop everything until all objects got their attribute list updated, any offsets previously obtained via C<classoffset> may still be bogus afterwards. And there is no way for the code that holds the offset to know that either.
Good point. It seems that after adding attributes to classes with instantiated objects, attribute access can only be done by attribute names with the current scheme. So if a class isn't marked final, attribute access is named only.
No, that's not the case. The offset returned is always found at runtime, and is always relative to the current structure of the object. It also should only be fetched by code which lives inside methods of a class.
The only time this offset will be incorrect is if the object structure changes between the time the offset is fetched and the time that the offset is used, which is something that needs guarding against.
The common case, by far, is to have objects that don't change structure. It looks like the common case will also be to have methods accessing multiple slots of an object in one go, though that's a bit dodgier of an assumption. In that case, the current scheme's faster.
Also, don't forget that the current scheme supports selector namespaces with fewer hoops to jump through, if we so desire. There's also the speed win for those cases where the hierarchy's locked such that new attributes *can't* be added.
I think I'd like to keep the scheme as-is for now. We can talk about what we need to do to ensure consistency when we're in a position to add attributes after the fact. (Those may well have to be accessed by name--we can work the scheme out after we get the current stuff actually functioning...)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
