On Thu, 26 Feb 2004, Dan Sugalski wrote: > At 2:38 PM +0100 2/26/04, Leopold Toetsch wrote: > >Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> At 8:10 AM +0100 2/26/04, Leopold Toetsch wrote: > >>> > >>>*Please* don't. C<classoffset> (and attribute access) should by all > >>>means start with 0. > > > >> Why? > > > >Simplifies compilers: > > > > newclass P1, "Foo" > > addattribute P1, "i" > > findclass I1, "Foo" > > new P2, I1 > > > > classoffset I2, P2 > > > >In static cases, where P2 is known to be a C<Foo>, attrib #0 ("i") would > >be always 0. That is, the C<classoffset> opcode can be omitted in that > >case. > > That's a very rare case, honestly, and since arguably every object is > a subclass of the base object class and people will end up sticking > attributes and methods into the base object class it's going to > happen anyway. > > I think I'd rather leave it as a non-zero, non-guaranteed base offset. > > > > No, it won't. No code should ever assume an absolute offset. That in > >> itself's broken. > > > >like t/pmc/objects.t? > > I was waiting for you to pull that out. :) Yes, objects.t assumes > some evil low-level knowledge of the internals.
Well, in part that's because classoffset wasn't implemented when I started writing the tests, so I had to use absolete offsets. Do you want me to rework it to be less evil? Simon