Ladies and gentlemen, I give you... objects!
Dan Sugalski
work now, modulo a test that needs a thump. If folks would abuse this
heavily, I'd much appreciate it.
Y'know, we may well make that Feb 30th date after all. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Simon Glover
On Wed, 25 Feb 2004, Dan Sugalski wrote:
> Yep, it looks like everything that should work now actually *does*
> work now, modulo a test that needs a thump. If folks would abuse this
The test has now been thumped. All tests now pass here. Of course, that
just means that it's time to write some more than don't... :-)
Simon
Chromatic
> Yep, it looks like everything that should work now actually *does*
> work now, modulo a test that needs a thump. If folks would abuse this
> heavily, I'd much appreciate it.
I'll revise some of the SDL code to use objects instead of pseudo
objects.
While I'm at it, is there nice IMCC syntactic sugar for making method
calls, or do I have to fill in the registers myself? It's quite nice to
write:
($I2, $I3) = _some_function_call( $I0, $I1 )
It'd be a shame not to have something similar for methods....
-- c
Leopold Toetsch
> While I'm at it, is there nice IMCC syntactic sugar for making method
> calls, or do I have to fill in the registers myself? It's quite nice to
> write:
> ($I2, $I3) = _some_function_call( $I0, $I1 )
Not yet. But you could try to prepend one instruction
P2 = the_object
> It'd be a shame not to have something similar for methods....
Please read Melvins proposal. There will be of course support for it,
but not just now.
> -- c
leo
Leopold Toetsch
> Yep, it looks like everything that should work now actually *does*
> work now
I've committed some fixes and more tests. Dan, can you please have a
look at:
$ perl -Ilib t/pmc/objects.t
[ snip ]
ok 23 - attribute values and subclassing 2
and add some comments WRT
- subclass vs addparent
- classoffset and attribute offsets of subclassed objects, e.g.
how to get at the very first attribute
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> Yep, it looks like everything that should work now actually *does*
>> work now
>
>I've committed some fixes and more tests. Dan, can you please have a
>look at:
>
>$ perl -Ilib t/pmc/objects.t
>[ snip ]
>ok 23 - attribute values and subclassing 2
>
>and add some comments WRT
>
>- subclass vs addparent
I'll update PDD15.
>- classoffset and attribute offsets of subclassed objects, e.g.
> how to get at the very first attribute
Which very first attribute? The first attribute for a class, or the
first attribute in the object?
Leopold Toetsch
> At 6:22 PM +0100 2/26/04, Leopold Toetsch wrote:
>>- classoffset and attribute offsets of subclassed objects, e.g.
>> how to get at the very first attribute
> Which very first attribute? The first attribute for a class, or the
> first attribute in the object?
Object of course:
The opcode is:
classoffset Ioffs, PObject, Sclass
I/the compiler wants an offset to be able to set/get attributes for that
object. But what shall go into "Sclass". The objects class, the parent,
which parent ...
And does the compiler know all parents?
Attribute offsets are adjacent (currrently 2+ ...). Can a compiler emit
just offsets from Ioffs .. Ioffs+n_attribs - 1, like in the mentioned
test?
Are there rules if a parent class attribs comes first/last?
If not: Getting all the offsets for object and parents needs currently
and instantiation of the parents just to query the offset.
This signature:
classoffset Ioffs, PObject, Pclass
would probably be better for that case - or generally for speed reasons.
And eventually
s/classoffset/atribute_offset/
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> At 6:22 PM +0100 2/26/04, Leopold Toetsch wrote:
>>>- classoffset and attribute offsets of subclassed objects, e.g.
>>> how to get at the very first attribute
>
>> Which very first attribute? The first attribute for a class, or the
>> first attribute in the object?
>
>Object of course:
Ah, OK. You don't.
>The opcode is:
>
> classoffset Ioffs, PObject, Sclass
>
>I/the compiler wants an offset to be able to set/get attributes for that
>object. But what shall go into "Sclass". The objects class, the parent,
>which parent ...
>And does the compiler know all parents?
The compiler doesn't have to know anything about the parents. All it
knows about is the current class, the one it's compiling the method
its' working on into. That's the class that goes in the Sclass slot.
>Attribute offsets are adjacent (currrently 2+ ...). Can a compiler emit
>just offsets from Ioffs .. Ioffs+n_attribs - 1, like in the mentioned
>test?
Yes. The assumption is that the compiler will track which attributes
were emitted for a class, and in which order.
>Are there rules if a parent class attribs comes first/last?
Nope. They can go in any order, though currently all the parent
classes come first to make adding attributes easier. We're not
promising that.
>If not: Getting all the offsets for object and parents needs currently
>and instantiation of the parents just to query the offset.
There's no reason that anything outside the Evil Core Object Code
should have to know anything about the structure of an object, or its
internal layouts.
The rule is that a method in a class has access to the attributes for
that class and nothing else. We're not enforcing that rule at the low
level, but compilers should never emit code for a method that has any
knowledge of attributes outside the class the method is compiled into.
>This signature:
>
> classoffset Ioffs, PObject, Pclass
>
>would probably be better for that case - or generally for speed reasons.
Maybe, but not by much. Within a method the class offset should be
fetched only once. I'm not sure there's much of a speed win there
since you still have to fetch the PMC for the class. I suppose it's
in a slot in the object, though, so it's pretty quick.
It can go in if you want, or hold off for 0.1.1. Your call.
>And eventually
>
> s/classoffset/atribute_offset/
Well... I suppose. Class_attribute_offset really. I think we'll stick
with classoffset for now, though.
Leopold Toetsch
> The rule is that a method in a class has access to the attributes for
> that class and nothing else.
Ah, that was the reason of my confusion. Could you adapt the docs
accordingly:
,--[ pdd15 ]---------------------------------------------------
| DESCRIPTION
| This is a reasonably straightforward object system. It
| assumes that objects have:
| ...
| and that you can:
| ...
| · Get an attribute by name or offset
|
| · Set an attribute by name or offset
`--------------------------------------------------------------
This takes for granted that you can manipulate any attributes of an
object w/o any constraint.
> ... We're not enforcing that rule at the low
> level, but compilers should never emit code for a method that has any
> knowledge of attributes outside the class the method is compiled into.
How *should* is "should"? Will Parrot automatically provide attribute
get/set functions (e.g. via some class .pragma)?
>> classoffset Ioffs, PObject, Pclass
> It can go in if you want, or hold off for 0.1.1. Your call.
Its not needed. The current scheme is fine.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> The rule is that a method in a class has access to the attributes for
>> that class and nothing else.
>
>Ah, that was the reason of my confusion. Could you adapt the docs
>accordingly:
Yep. I'll patch that up.
> > ... We're not enforcing that rule at the low
>> level, but compilers should never emit code for a method that has any
>> knowledge of attributes outside the class the method is compiled into.
>
>How *should* is "should"? Will Parrot automatically provide attribute
>get/set functions (e.g. via some class .pragma)?
Nope. If a language wants to provide get/set methods for class
attributes it needs to create those methods at compilation time.
Larry Wall
: Nope. If a language wants to provide get/set methods for class
For Perl 6 it's a single method that might be lvaluable depending on
the declaration of the attribute.
Larry
Dan Sugalski
Well, one method per attribute/property/slot/Fred/Barney/Thingie.
Which is what I meant, though not altogether clearly...
Joseph Ryan
Right, but the compiler should be able to figure that out and emit
the proper code.
- Joe
Larry Wall
Yes, but it'd be nice not to force the compiler to generate a heavy
proxy object for every lvaluable accessor to something that already
knows how to fetch and store. We just need to make sure that the
attribute can serve as its own proxy. That means the interface to an
attribute should be identical to the interface to a variable, once
you've taken a reference to it. We're trying to make a big deal of
the notion that you can use an "is rw" method call anywhere you can
use a variable. It'd just be nice if that didn't suck overly much.
Larry