On Wed, 25 Feb 2004, Dan Sugalski wrote:
At 4:54 PM -0500 2/25/04, Simon Glover wrote: > If I'm understanding the docs correctly, this should print '0'. > Instead, it prints 'Array index out of bounds!'
Another bug, though the offset ought to be 2 right now. (Attributes 0 and 1 are taken by other things so they're valid)
OK, I think I see what's going on now: attribute 0 is the class PMC, attribute 1 is the classname PMC, and then any other attributes go into slots 2+
However, there's currently nothing to stop you stomping on the PMCs in slots 0 and 1 by setting attributes with those offsets: in other words, doing:
newclass P1, "Foo" addattribute P1, "i" find_type I0, "Foo" new P2, I0
new P3, .PerlInt set P3, 1024 setattribute P2, 1, P3
works, but changes the classname PMC to be a PerlInt with a value of 1024. Are we supposed to be able to do this?
Yes. At least... sorta kinda yes. Everything inside an object's attributes that's outside the range (class_offset .. class_offset+class_attrib_count] is supposed to not be touched.
This all assumes that compilers will generate correct code, and at the moment there's no reason, other than for testing, to use absolute offsets--the ops to do it all relatively are there and work. We may hide or otherwise protect these slots in the future--right now I'm happy with it all working as long as you don't poke it too hard. (Many of the functions don't properly check for class or objectness, for example)
A second issue (and what confused me in the first place) is that in your attribute example in PDD 15 you have:
Adding the attributes C<a> and C<b> to the new class C<Foo>:
newclass $P0, "Foo" addattribute $P0, "a", "Foo::a" # This is offset 0 addattribute $P0, "b", "Foo::b" # This is offset 1
I assume that this should actually refer to offsets 2 and 3?
Yes. That example's wrong and I'll go fix it.
Finally, in looking at the ops code, I noticed an unrelated bug: in the classname op, you do:
classname_pmc = VTABLE_get_pmc_keyed_int(interpreter, (PMC *)PMC_data($2), POD_CLASS_NAME);
To get the classname for the PMC. The problem is that the op is documented as working with a PMC respresenting a class, but you're using the symbolic constant from the object enum. This currently works, since the classname PMC is stored in slot 1 in both a ParrotObject and a ParrotClass PMC, but it still looks like a bug.
D'oh! I'll go fix. Though since classes are supposed to be objects you could argue that it's actually correct, other than the fact that it's wrong. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
