Using Ruby Objects with Parrot
Mark Sparshatt
I've been reading PDD15. It seems that if the object foo is an instance
of the class Foo then foo is a ParrotObject pmc and Foo is a ParrotClass
pmc.
From the description in PDD15 I'm not sure how to hand languages where
a class is also an object. Where Foo is an instance of Foo' which is an
instance of Class.
The three solutions I can see are
1: Let one ParrotObject be an instance of another ParrotObject, so that
Ruby would just use ParrotObjects for it's object system
2: Let one ParrotClass be an instance of another ParrotClass
3: Create a ParrotMetaClass pmc, so Class and Foo' would be
ParrotMetaClasses, Foo would be a ParrotClass and foo would be a
ParrotObject
I think this will also be an issue with Python since that allows classes
to have metaclasses.
--
Mark Sparshatt
Dan Sugalski
>Hi,
>
>I've been reading PDD15. It seems that if the object foo is an
>instance of the class Foo then foo is a ParrotObject pmc and Foo is
>a ParrotClass pmc.
>
>From the description in PDD15 I'm not sure how to hand languages
>where a class is also an object. Where Foo is an instance of Foo'
>which is an instance of Class.
Okay, I'm going to be dense here for a bit, as I just don't do
objects. (Well, except grudgingly, and with an inordinate amount of
grumbling) So the big question is... What Does This Mean? I'm
reasonably sure (though not 100% sure) that classes can only inherit
from classes, not objects, so there's none of this template object
stuff to deal with. The ParrotObject PMC inherits from the
ParrotClass PMC, so there's a lot of overlap, so... what can one do
with a class that makes it a metaclass? (Yeah, I do realize I'm more
or less asking a "Recap the last 30 years of OO theory for Dummies"
question, but I'm not sure I'm familiar enough with things to ask a
better one)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Karl Brodowsky
> From the description in PDD15 I'm not sure how to hand languages where
> a class is also an object. Where Foo is an instance of Foo' which is an
> instance of Class.
Could this be handled during compilation?
The compiler could produce the classes Foo and Foo' and use something like
Ruby-Class from a library. Then Foo could contain a hidden reference to
Foo', using a convention that the compiler can handle. I would expect that
the dependency on Ruby-libraries still exist, when running compiled Ruby
anywhere where Perl6 has been installed.
Best regards,
Karl
Mark Sparshatt
gone to the mailing list :-/
Dan Sugalski wrote:
> At 10:22 PM +0000 3/12/04, Mark Sparshatt wrote:
>
>> Hi,
>>
>> I've been reading PDD15. It seems that if the object foo is an
>> instance of the class Foo then foo is a ParrotObject pmc and Foo is a
>> ParrotClass pmc.
>>
>> From the description in PDD15 I'm not sure how to hand languages
>> where a class is also an object. Where Foo is an instance of Foo'
>> which is an instance of Class.
>
>
> Okay, I'm going to be dense here for a bit, as I just don't do
> objects. (Well, except grudgingly, and with an inordinate amount of
> grumbling) So the big question is... What Does This Mean? I'm
> reasonably sure (though not 100% sure) that classes can only inherit
> from classes, not objects, so there's none of this template object
> stuff to deal with. The ParrotObject PMC inherits from the ParrotClass
> PMC, so there's a lot of overlap, so... what can one do with a class
> that makes it a metaclass? (Yeah, I do realize I'm more or less asking
> a "Recap the last 30 years of OO theory for Dummies" question, but I'm
> not sure I'm familiar enough with things to ask a better one)
I'm not 100% certain about the details but I think this is how it works.
In languages like C++ objects and classes are completely seperate.
classes form an inheritance heirachy and objects are instances of a
particular class.
However in some languages (I think that Smalltalk was the first) there's
the idea that everything is an object, including classes. So while an
object is an instance of a class, that class is an instance of another
class, which is called the metaclass. I don't there's anything special
about these classes other than the fact that their instances are also
classes.
Thinking about it I think you may have the relationship between
ParrotObject and ParrotClass the wrong way around. Since a class is an
object but and object isn't a class it would be better for ParrotClass
to inherit from ParrotObject, rather than the other way round.
In Ruby when you create a class Foo, the Ruby interpreter automatically
creates a class Foo' and sets the klass attribute of Foo to point to Foo'.
This is important since class methods of Foo are actually instance
methods of Foo'. Which means that method dispatch is the same whether
you are calling an instance of class method.
foo.method()
looks at foo's klass attribute then checks the returned class object
(Foo) for method
Foo.method()
looks at Foo's klass attribute and again checks the returned class
object (Foo') for method.
The Pickaxe book has got a better explanation of this (at
http://www.rubycentral.com/book/classes.html though without any diagrams
:( )
In Python when defining a class it's possible to set an attribute in the
class that points to the classes metaclass. The metaclass itself is just
a normal class that defines methods which override the normal behaviour
of the class.
IIRC Python has got both class methods and meta class instance methods
which work almost (but not quite) in the same way as each other.
Hopefully someone with more experience with Python will be able to
explain better.
I'm not sure if this has cleared things up or just made them more confusing.
--
Mark Sparshatt
Mark Sparshatt
Karl Brodowsky wrote:
you're right this is something that the compiler could handle.
The problem is what happens when some Python code tries to call a class
method on a Ruby object? if Python doesn't know about the hidden
reference within Foo it won't be able to find Foo' in order to call the
method.
I think that if different languages are going to interoperate then this
either needs to be handled within Parrot, or if it is handled by the
compiler than there needs to standard approach.
--
Mark Sparshatt
Karl Brodowsky
> The problem is what happens when some Python code tries to call a class
> method on a Ruby object? if Python doesn't know about the hidden
> reference within Foo it won't be able to find Foo' in order to call the
> method.
The issue you are addressing is finding the applicable methods.
The rules where to look when the object itself does not have the
method. But mechanisms like this are needed for anything that seriously
calls itself OO-language. And these mechanisms can be quite different if
we consider Perl6, Java, C++, CLOS, Smalltalk, PHP, Eiffel, Ada, Ruby or
Python (not that I know all of those...). And I understand that the
method dispatching mechanism of Parrot should be powerful enough to
cover at least Perl6, Ruby and Python. But does the way to achieve this
have to be exactly how Ruby actually does it? Or is it enough if the
way is well defined? These interlanguage-calls might have some extra
complexity, at least that's my experience whenever you do something like
that, due to different semantics.
Best regards,
Karl
P.S. I should learn Ruby.
Mark Sparshatt
I don't think that Parrot needs to exactly mimic the way Ruby handles
method dispatch but there does need to be a well defined way.
--
Mark Sparshatt
Brent "Dax" Royal-Gordon
> The problem is what happens when some Python code tries to call a class
> method on a Ruby object? if Python doesn't know about the hidden
> reference within Foo it won't be able to find Foo' in order to call the
> method.
If I understand correctly, the Ruby object, as represented by a
RubyObject PMC, knows about Foo'. That's enough, because the RubyObject
handles the method dispatch anyway.
Let's say some Python code has a Ruby object, 'foo'. This Ruby object
has a method named 'bar' in it. The code to call it would be something
like this:
set P2, foo
callmethod "bar"
That's it.
Really.
Well, not really, because there's all sorts of crud you have to set up
under the Parrot calling convention. But the point is that the Python
code doesn't go poking around in foo's guts to find the method--it just
says, "Okay, foo, go run this method". foo is a RubyObject, so it
dispatches according to Ruby's rules, even though it was called by Python.
If foo wasn't a Ruby object, but instead belonged to a language where
dispatches are based on the phase of the moon, you'd better check your
almanac, because your call from Python will reflect that too.
For a class method, I assume it'd look something like this:
getclass P2, foo
callmethod "bar"
Once again, no poking around in foo's guts. Just "gimmie your class"
followed by "run your bar".
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Mark Sparshatt
Those are good points. There's no need for Python and other languages to
know how Ruby handles it's method dispatch since it would be
encapsulated in the RubyObect pmc's vtable functions.
I like the idea of a language where method dispatch is determined by the
phase of the moon. I would suggest calling it Luna but I that that names
been used already.
Thanks for the help
--
Mark Sparshatt
Nick Ing-Simmons
>
>I'm not 100% certain about the details but I think this is how it works.
>
>In languages like C++ objects and classes are completely seperate.
>classes form an inheritance heirachy and objects are instances of a
>particular class.
>
>However in some languages (I think that Smalltalk was the first) there's
>the idea that everything is an object, including classes. So while an
>object is an instance of a class, that class is an instance of another
>class, which is called the metaclass. I don't there's anything special
>about these classes other than the fact that their instances are also
>classes.
>
>
>Thinking about it I think you may have the relationship between
>ParrotObject and ParrotClass the wrong way around. Since a class is an
>object but and object isn't a class it would be better for ParrotClass
>to inherit from ParrotObject, rather than the other way round.
>
>In Ruby when you create a class Foo, the Ruby interpreter automatically
>creates a class Foo' and sets the klass attribute of Foo to point to Foo'.
>
>This is important since class methods of Foo are actually instance
>methods of Foo'. Which means that method dispatch is the same whether
>you are calling an instance of class method.
So in perl5-ese when you call
Foo->method
you are actually calling sub Foo::method which is in some sense
a "method" of the %Foo:: "stash" object.
So what you suggest is as if perl5 compiled Foo->method
into (\%Foo::)->method and the %Foo:: 'stash' was blessed...
Piers Cawley
Personally, I've always wished that Perl5 *had* done that. I've toyed
with the idea of blessing Stashes, but never got around to actually
implementing anything.
Larry Wall
: Personally, I've always wished that Perl5 *had* done that. I've toyed
: with the idea of blessing Stashes, but never got around to actually
: implementing anything.
Well, hey, we had to leave something to fix in Perl 6.
What? Oh, right. Nevermind.
Larry