Object spec
Dan Sugalski
most of the revamp of PDD15 (objects!) is checked into the
repository. It'd be worth checking it out and checking it out, as
this would be the time to get comments in.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Simon Glover
Here's a patch to fix various typos etc. that I noticed on going over
the spec.
Simon
--- pdd15_objects.pod.old Fri Feb 13 17:06:46 2004
+++ pdd15_objects.pod Fri Feb 13 17:10:08 2004
@@ -174,7 +174,7 @@
=item *
-remove interfaces
+Remove interfaces
=back
@@ -209,13 +209,13 @@
hold all the per-object instance data. ParrotClass PMCs hold all the
class-specific information. Instantiating a new OO class creates a new
ParrotClass PMC, and enters the new OO class into Parrot's PMC class
-table, at which point it is indistiguishable from any other PMC
+table, at which point it is indistinguishable from any other PMC
class. (This doesn't mean that non-ParrotClass things can be
subclassed or treated as an OO class. Neither is that forbidden. Just
unimplemented)
It's important to note that I<all> 'standard' classes are
-ParrotClass PMC instancess, and I<all> 'standard' objects are
+ParrotClass PMC instances, and I<all> 'standard' objects are
ParrotObject PMCs. We do I<not> create a brand new PMC class for each
OO class, and they all share the ParrotClass or ParrotObject vtable,
respectively. This distinction is mostly an artifact of the
@@ -252,7 +252,7 @@
The class attribute name hash. Keys are the fully qualified attribute
names (in whatever format the language governing the class wants) and
-the values are the offset from the beginnign of the attribute array of
+the values are the offset from the beginning of the attribute array of
the particular attribute.
=back
@@ -265,7 +265,7 @@
ParrotClass PMCs also have the "I am a class" flag set on them.
-The ParrotObject PMC is an array of metainformation and
+The ParrotObject PMC is an array of meta-information and
attributes. The elements of this array are:
=over 4
@@ -317,7 +317,7 @@
=item setattr Px, Sy, Pz
-Set the attribute of obbect Px with the fully qualified name Sy to Pz
+Set the attribute of object Px with the fully qualified name Sy to Pz
=item fetchmethod Px, Py, Sz
Simon Glover
A few questions:
1) How is the search order for the parents of a particular class
specified? In particular, is this determined at the Parrot level
or at the language level? Can it change at runtime?
2) Re. the classoffset op: how does this work when multiple parent
classes specify the same attribute?
For instance, suppose 'foo' is the first attribute specified in
classes 'Bar' and 'Baz', which are theselves unrelated (i.e. 'Bar'
doesn't inherit from 'Baz', nor vice versa), but which are both
parent classes of a third class 'Qux'. Now, if P0 holds an object
of class 'Qux', does:
classoffset I0, P0, 'Bar'
return the same value as:
classoffset I0, P0, 'Baz'
or not?
3) If more than one parent class specifies a particular attribute,
do all of these parents have to be removed before the attribute
is removed?
Regards,
Simon
Leopold Toetsch
> While I'm still working on the vtable and supporting code section,
> most of the revamp of PDD15 (objects!) is checked into the
> repository. It'd be worth checking it out and checking it out, as
> this would be the time to get comments in.
1) Why is the existing opcode B<find_method> now B<fetchmethod>? Or do
they different things?
2) B<classoffset> isn't really needed.
set I0, PClass["attr"]
exists and is working
3) The same holds for B<setattr> and B<getattr>
set PObj["attr"], Pattr
set PObj[0], Pattr
are implemented and working. *And* this syntax allows also
set PObj[0], 42 # set attr #0 from constant
set PObj["answer"], 42
The B<{g,s}etattr> are only allowing PMC attribute values.
Now we could of course say that B<getattr> is somewhat more descriptive
then the keyed access. OTOH the keyed access matches perl5s blessed ref
of array or hash syntax and avoids increased opcode count (the more, if
native types are to be handled too).
And finally - I asked that already a few times - how does B<"attr">
above really look like? Is this a full qualified name? Or only when two
classes have the same attribute?
Please have a look at t/pmc/obj*.t for the current state.
leo
Lf
> most of the revamp of PDD15 (objects!) is checked into the repository.
> It'd be worth checking it out and checking it out, as this would be
> the time to get comments in.
great to see this, i guess everyone will agree. well, i have some
questions...
what i couldn't find is how to register a method address and name with
a class,
so that fetchmethod will return it? am i looking in the wrong place?
the instantiate opcode takes 'metadata' as its second argument. how is
this
supposed to be constructed and when is this method of creating a new
class
appropriate instead of newclass and subclass ops?
LF
Dan Sugalski
> Here's a patch to fix various typos etc. that I noticed on going over
> the spec.
D'oh! Applied, thanks.
Dan Sugalski
> A few questions:
>
> 1) How is the search order for the parents of a particular class
> specified? In particular, is this determined at the Parrot level
> or at the language level? Can it change at runtime?
It's determined by the method invocation code.
> 2) Re. the classoffset op: how does this work when multiple parent
> classes specify the same attribute?
>
> For instance, suppose 'foo' is the first attribute specified in
> classes 'Bar' and 'Baz', which are theselves unrelated (i.e. 'Bar'
> doesn't inherit from 'Baz', nor vice versa), but which are both
> parent classes of a third class 'Qux'. Now, if P0 holds an object
> of class 'Qux', does:
>
> classoffset I0, P0, 'Bar'
>
> return the same value as:
>
> classoffset I0, P0, 'Baz'
>
> or not?
Nope. When the Qux class is constructed the offsets for each of its
parent classes (and their parent classes,a nd so on) are calculated,
and are effectively custom on a per-class basis. So if we had the
following classes with attributes:
Bar:
a
b
c
Baz:
x
y
z
and we had Qux and Xyzzy like so:
Qux: isa(Bar, Baz)
Xyzzy: isa(Baz, Bar)
Then you had code that looked like:
new P0, .Qux
new P1, .Xyzzy
classoffset I0, P0, 'Bar'
classoffset I1, P1, 'Bar'
print I0
print "\n"
print I1
print "\n"
you'd get:
2
5
(Because the first few attributes are reserved) *However*....
Attribute "b" is always at classoffset("Bar") + 1, regardless of
where Bar is in the attribute list.
Basically any class code that directly accesses attributes should
first query where that class's base offset is for the object in
question and work from there.
I think I need to add in an example section.
> 3) If more than one parent class specifies a particular attribute,
> do all of these parents have to be removed before the attribute
> is removed?
Currently yes. That also means a class can have its attributes in the
hierarchy only once, regardless of how many times it actually appears.
Dan Sugalski
>>While I'm still working on the vtable and supporting code section,
>>most of the revamp of PDD15 (objects!) is checked into the
>>repository. It'd be worth checking it out and checking it out, as
>>this would be the time to get comments in.
>
>great to see this, i guess everyone will agree. well, i have some questions...
>
>what i couldn't find is how to register a method address and name
>with a class,
>so that fetchmethod will return it? am i looking in the wrong place?
Not gotten there yet. :)
By default methods are in class namespaces, so fetchmethod would (by
default, mind) just look in each class namespace in the parent array
for the method until it finds one. We're going to provide method
caches, since otherwise performance will really suck, but that's an
optimiziation.
>the instantiate opcode takes 'metadata' as its second argument. how is this
>supposed to be constructed and when is this method of creating a new class
>appropriate instead of newclass and subclass ops?
I was wondering if someone'd catch that. The metadata stuff is
entirely unspecified, but it's in there for later. (Or, rather,
not-quite-now) It's to be used in the case where you have all the
info for a class at instantiation time and want to be able to say
"make me a class with parents X, Y, and Z, and eighteen attributes
with these names" and do it in one go, rather than as a series of
addparent and addattribute ops.
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> While I'm still working on the vtable and supporting code section,
>> most of the revamp of PDD15 (objects!) is checked into the
>> repository. It'd be worth checking it out and checking it out, as
>> this would be the time to get comments in.
>
>1) Why is the existing opcode B<find_method> now B<fetchmethod>? Or do
>they different things?
Same thing. The difference is a result of my lousy memory and lack of research.
>2) B<classoffset> isn't really needed.
>
> set I0, PClass["attr"]
>
> exists and is working
Pretty much all of the current object stuff is getting yanked out and
replaced. It's first draft and needs redoing.
>And finally - I asked that already a few times - how does B<"attr">
>above really look like? Is this a full qualified name? Or only when two
>classes have the same attribute?
That was specified in the PDD. *If* a class is looking up by name,
something it generally won't do, it uses the fully-qualified name of
the attribute, in the format that the class wants. Since a class is
soley responsible for its naming scheme this should be reasonably
safe.
>Please have a look at t/pmc/obj*.t for the current state.
Those'll need to be redone as well. Something for later, when the spec is done.