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
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
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.
> *) 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/
--------------------------------------
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
> 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. :/
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
> 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. :)
> 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
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?
> 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 <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?
>> $ 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