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
>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.
>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. -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
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!)
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.
.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.
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. :/
> 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 :-)
> 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. :/
> Sincerely,
> Michal J Wallace > Sabren Enterprises, Inc. > ------------------------------------- > contact: mic...@sabren.com > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > --------------------------------------
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?
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)
