Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Objects!

9 views
Skip to first unread message

Dan Sugalski

unread,
Dec 2, 2003, 10:52:18 AM12/2/03
to perl6-i...@perl.org
Well, objects-ish, at least.

Single-inheritance objects seem to be done. The code can use a lot of
abuse and cleanup, and we need actual tests to make sure that it
functions as it should, but they're in.

Here's the technical scoop.

When you create a ParrotClass-based class (which is to say, you use
the class creation ops that we provide) you get a class PMC that's
got all the class information hanging off it. This stuff's documented
at the top of classes/parrotclass.pmc though better docs are
definitely in order.

Since creating the class is handled by the code in objects.c rather
than in the class vtable, we get to play a number of games:

Games we play:
==============
*) The class code knows its dealing with parrot classes (there's a
flag to tell us) and it cheats. Not too badly, but some. Probably
should cheat more, but I'm up for getting it working before doing
Horribly Evil Things.
*) Creating new objects involves calling the ->init vtable entry *on
the class*. Because of this each class gets a custom vtable where the
init method has been swapped out for one (from objects.c) that
creates a new object instead.

But it seems to work out. Slowly (no method cache definitely hurts)
but still, works is good. The PMC that the class ->init method hands
back is a ParrotObject, rather than a ParrotClass, which is good as
it's an object and all. The vtable on the object is currently the
base ParrotObject vtable which, as you can probably see, doesn't do a
whole lot besides method calls.

Still to do:
============
*) Multiple inheritance
*) Runtime inheritance changes
*) Runtime attribute changes
*) Metadata support for class creation
*) Tests to make sure it actually, y'know, works.
*) Delegation of vtable methods to methods in the class
*) fallback method finding

Happy "Abuse the Objects" day, everyone. :)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Melvin Smith

unread,
Dec 2, 2003, 10:09:49 PM12/2/03
to Dan Sugalski, perl6-i...@perl.org
At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote:
>Single-inheritance objects seem to be done. The code can use a lot of
>abuse and cleanup, and we need actual tests to make sure that it functions
>as it should, but they're in.

Let me start the abuse.

*(cough)* examples would be nice ;)

Ok, abuse over. I am just happy we are moving again.

>*) Creating new objects involves calling the ->init vtable entry *on the
>class*. Because of this each class gets a custom vtable where the init
>method has been swapped out for one (from objects.c) that creates a new
>object instead.

So do you want an init op added to object.ops or is there something I am
missing.
I did toss in 'isa', although the implementation is wrong as you said.

-Melvin


Dan Sugalski

unread,
Dec 2, 2003, 10:38:57 PM12/2/03
to Melvin Smith, perl6-i...@perl.org
At 10:09 PM -0500 12/2/03, Melvin Smith wrote:
>At 10:52 AM 12/2/2003 -0500, Dan Sugalski wrote:
>>Single-inheritance objects seem to be done. The code can use a lot
>>of abuse and cleanup, and we need actual tests to make sure that it
>>functions as it should, but they're in.
>
>Let me start the abuse.
>
>*(cough)* examples would be nice ;)

Examples? We don' need no steenkin' examples! :-P

>>*) Creating new objects involves calling the ->init vtable entry
>>*on the class*. Because of this each class gets a custom vtable
>>where the init method has been swapped out for one (from objects.c)
>>that creates a new object instead.
>
>So do you want an init op added to object.ops or is there something
>I am missing.
>I did toss in 'isa', although the implementation is wrong as you said.

Nah. new works just fine for objects, as it ought.

Michal Wallace

unread,
Jan 7, 2004, 7:07:48 PM1/7/04
to Dan Sugalski, perl6-i...@perl.org
On Tue, 2 Dec 2003, Dan Sugalski wrote:

> *) Creating new objects involves calling the ->init vtable entry *on
> the class*. Because of this each class gets a custom vtable where the
> init method has been swapped out for one (from objects.c) that
> creates a new object instead.

Well, cool! How do I this from parrot?

I've been trying things along the lines of:

.sub _main
.local object Cat
.local object felix
newclass Cat, "Cat"
P2 = Cat
S0 = "init"
callmeth
felix = P0
#...
end
.end

... But haven't figured out the magic formula yet
That code above gives:

Method 'init' not found
in file '(unknown file)' near line -1


(If anyone can post a working example of the code
above I'd really appreciate it!)


Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

Luke Palmer

unread,
Jan 7, 2004, 8:01:44 PM1/7/04
to Michal Wallace, Dan Sugalski, perl6-i...@perl.org
Michal Wallace writes:
> On Tue, 2 Dec 2003, Dan Sugalski wrote:
>
> > *) Creating new objects involves calling the ->init vtable entry *on
> > the class*. Because of this each class gets a custom vtable where the
> > init method has been swapped out for one (from objects.c) that
> > creates a new object instead.
>
> Well, cool! How do I this from parrot?
>
> I've been trying things along the lines of:
>
> .sub _main
> .local object Cat
> .local object felix
> newclass Cat, "Cat"
> P2 = Cat
> S0 = "init"
> callmeth
> felix = P0
> #...
> end
> .end

Should go something like this:

.sub _main
.local object Cat
.local object felix
newclass Cat, "Cat"

find_type $I0, "Cat"
felix = new $I0
# ...
.end

But note that objects are unfinished. I ran into a certain problem when
I assumed that attributes could be any type of data; not so -- they can
only be integers (at the moment). I needed object support right away,
so I simulated using a hash. The hash has a "CLASS" key which holds the
class to which it belongs. I then use this to get the methods.

Luke

Michal Wallace

unread,
Jan 7, 2004, 9:50:41 PM1/7/04
to Luke Palmer, Dan Sugalski, perl6-i...@perl.org
On Wed, 7 Jan 2004, Luke Palmer wrote:

> Should go something like this:
>
> .sub _main
> .local object Cat
> .local object felix
> newclass Cat, "Cat"
> find_type $I0, "Cat"
> felix = new $I0
> # ...
> .end


Thanks, but that doesn't work either. :/
The "new" op expects an identifier. It won't
take a VAR, IREG, or REG.


> But note that objects are unfinished. I ran into a certain problem
> when I assumed that attributes could be any type of data; not so --
> they can only be integers (at the moment). I needed object support
> right away, so I simulated using a hash. The hash has a "CLASS" key
> which holds the class to which it belongs. I then use this to get
> the methods.

I'm not even trying to get objects working yet. I just
need something that'll let me run setprop on it so my
generators can make iterator "things" with a .next()
attached to them... I was using ParrotObjects and
ParrotClasss for a while but now you can't make a
new ParrotObject directly either. :/

Incidentally, anyone know why not? In python or
javascript it's easy to just create an object of
no particular class just to have a place to stick
things.

foo = object()
foo.x = 1

It was working fine in parrot too, but then it
went away. :/

Luke Palmer

unread,
Jan 7, 2004, 9:59:40 PM1/7/04
to Michal Wallace, Dan Sugalski, perl6-i...@perl.org
Michal Wallace writes:
> On Wed, 7 Jan 2004, Luke Palmer wrote:
>
> > Should go something like this:
> >
> > .sub _main
> > .local object Cat
> > .local object felix
> > newclass Cat, "Cat"
> > find_type $I0, "Cat"
> > felix = new $I0
> > # ...
> > .end
>
>
> Thanks, but that doesn't work either. :/
> The "new" op expects an identifier. It won't
> take a VAR, IREG, or REG.

Er, sorry, that's IMCC's fault. This works:

new felix, $I0

>
> > But note that objects are unfinished. I ran into a certain problem
> > when I assumed that attributes could be any type of data; not so --
> > they can only be integers (at the moment). I needed object support
> > right away, so I simulated using a hash. The hash has a "CLASS" key
> > which holds the class to which it belongs. I then use this to get
> > the methods.
>
> I'm not even trying to get objects working yet. I just
> need something that'll let me run setprop on it so my
> generators can make iterator "things" with a .next()
> attached to them... I was using ParrotObjects and
> ParrotClasss for a while but now you can't make a
> new ParrotObject directly either. :/

I know PerlArray accepts and stores properties: my compiler uses them.
PerlHash probably does too.

And thanks again for all the work you're doing on Python :-)

Luke

Michal Wallace

unread,
Jan 8, 2004, 2:28:15 AM1/8/04
to Luke Palmer, perl6-i...@perl.org
On Wed, 7 Jan 2004, Luke Palmer wrote:

> Er, sorry, that's IMCC's fault. This works:
>
> new felix, $I0

Yep! Thanks!

Here's a short example of the final script:

.sub _main
.local object Cat
.local object felix
newclass Cat, "Cat"
find_type $I0, "Cat"

new felix, $I0
$P0 = new PerlString
$P0 = "felix"
setprop felix, "name", $P0
getprop $P1, "name", felix
print "the cat's name is "
print $P1
print ".\n"
end
.end

> I know PerlArray accepts and stores properties: my compiler uses them.
> PerlHash probably does too.

Yeah, but I felt silly passing around a Hash or Array. :) I ALMOST
went withi this though until you showed me how to get the instantiation
working. :)


> And thanks again for all the work you're doing on Python :-)

Thanks for the register-stacks-for-continuations patch!
That should fix some bugs I've got with generators. :)

Leopold Toetsch

unread,
Jan 8, 2004, 5:51:33 AM1/8/04
to Michal Wallace, perl6-i...@perl.org
Michal Wallace <mic...@sabren.com> wrote:

> I'm not even trying to get objects working yet. I just
> need something that'll let me run setprop on it

You can attach properties to all PMCs. And WRT object instantiation:
t/pmc/object*.t but only integer attributes are done.


leo

Michal Wallace

unread,
Jan 8, 2004, 10:46:42 AM1/8/04
to Leopold Toetsch, perl6-i...@perl.org


Thanks. I looked at those last night but I didn't
get what I was looking at. Guess I should have
been more careful.

What exactly is the difference between an
attribute and a property?

Leopold Toetsch

unread,
Jan 8, 2004, 10:56:56 AM1/8/04
to Michal Wallace, perl6-i...@perl.org
Michal Wallace <mic...@sabren.com> wrote:

> What exactly is the difference between an
> attribute and a property?

$ perldoc docs/pdds/pdd15_objects.pod
/TRANSLATION AND GLOSSARY

> Michal J Wallace

leo

Michal Wallace

unread,
Jan 8, 2004, 12:19:39 PM1/8/04
to Leopold Toetsch, perl6-i...@perl.org
On Thu, 8 Jan 2004, Leopold Toetsch wrote:

> Michal Wallace <mic...@sabren.com> wrote:
>
> > What exactly is the difference between an
> > attribute and a property?
>
> $ perldoc docs/pdds/pdd15_objects.pod
> /TRANSLATION AND GLOSSARY

Thanks. Don't mind me. I'm going to go make
a card that says "RTFM" on my monitor here... :)

So let me see if I have this right. Attributes
are slots in a class, that get created on each
instance. Properties don't have predefined slots,
you can just attach whatever you want to any PMC.

So: a language like java would probably use
attributes, because the shape of the class is
defined before hand, whereas python would tend
to use properties... Right?

But when I actually go to fill in the slots,
I still use getprop/setprop for both types,
right? So if I setprop on an attribute-based-class
it would fill in the attribute first, and then
if the attribute slot isn't there, do something
else (like throw an exception or just make a property?)

I guess what I'm asking is: is getprop/setprop
a universal interface, or will we need some kind
of logic to know whether a particular object
uses attributes instead?

Leopold Toetsch

unread,
Jan 8, 2004, 2:22:12 PM1/8/04
to Michal Wallace, perl6-i...@perl.org
Michal Wallace <mic...@sabren.com> wrote:
> On Thu, 8 Jan 2004, Leopold Toetsch wrote:

>> $ perldoc docs/pdds/pdd15_objects.pod
>> /TRANSLATION AND GLOSSARY

> So let me see if I have this right. Attributes


> are slots in a class, that get created on each
> instance. Properties don't have predefined slots,
> you can just attach whatever you want to any PMC.

Yep. The "whatever you want" is another PMC though.

> So: a language like java would probably use
> attributes, because the shape of the class is
> defined before hand, whereas python would tend
> to use properties... Right?

Yes. Yes.

> But when I actually go to fill in the slots,
> I still use getprop/setprop for both types,
> right? So if I setprop on an attribute-based-class
> it would fill in the attribute first, and then
> if the attribute slot isn't there, do something
> else (like throw an exception or just make a property?)

No: Attributes aren't filled with setprop, that just sets a property.
And: what's happening if a non-existing property is set depends on the
HLL. Python's throwing AFAIK a NameError or such exception. Attributes
and properties are 2 different things to achieve similar effects. Perl6
will have both. Python would very likely use properties only.

> I guess what I'm asking is: is getprop/setprop
> a universal interface, or will we need some kind
> of logic to know whether a particular object
> uses attributes instead?

We will have to know, if an object originated from Python or Perl6, if
we want to mix library code. But don't nail me down on that. This all
depends on namespaces too, the order how we lookup attributes (or
properties) but its primary up to the HLL code to do the right thing.

(All AFAIK, which isn't much when objects are concerned)

> Michal J Wallace

leo

0 new messages