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
