[ruby-talk:30160] Re: more parrot-questions..

At 11:15 PM 1/3/2002 +0900, Erik B虍fors wrote:
>How is object-orientation going to be done in parrot??

It's generally going to be left to the various classes. Variables all have 
a "dispatch to named method" entry in their vtables, which Does The Right 
Thing. Which, presumably, includes dispatching to the actual method somehow. :)

So if your code does:

    someObject.hey_look_a_method

that gets translated, more or less, to:

    find_lex P0, 0, 7 # Assuming we're the seventh lexical in
                       # the current scope
    call_method P0, "hey_look_a_method"

Punting like this lets us leave method dispatch (and inheritance, and some 
other stuff) to the various classes. Some folks want single inheritance, 
some want multiple with single dispatch, some multiple with redispatch, 
some multiple with single dispatch and whines with multiple versions of the 
same routine... I don't care, so we abstract it out.

>If I use a perl-module from ruby under parrot and it creates a new
>object I should be able to use that from my ruby-code in the same way as
>if it was a ruby-object, right??

Right.

>In ruby all objects has the
>"Object"-class as it's parent-class, and as such we get some methods
>from that class in every object we create.
>
>If I get a perl-object will it still have all those methods when using
>ruby??

No. Neither will a python object, or a smalltalk object. What you get 
depends on what the object provides and what it inherits. Parrot, as an 
interpreter engine, isn't mandating any sort of object or class hierarchy, 
as that's really not its place.

>I don't know python very well but I assume that it also has a
>"base-class" like "Object" above?  What happens if I use a python-object
>from ruby?  Will it have both "Object" and what-ever-python-uses as
>parents??  That would mean multiple inheritance which ruby (and I think
>python) does not support.

I don't know if python's got a base class, but if it does then python 
objects only have that base class, not base and Object.

As far as the interpreter's concerned, there's really no single superclass 
that provides any methods or behaviour. (Well, unless you count the "you 
lose,  program dies" routine which'll get filled in for any vtable entries 
you haven't supplied, but the vtable's a bit below methods and such.

If Matz, Larry, and Guido (or some subset of the three) get together and 
agree on a common set of default methods, then I'll make sure they get in 
and implemented. (It's not my job to define behaviour, just to design and 
get implemented the engine that provides the behaviour other people define)

>What about native-modules?  Do they have to be written in "parrot-c"
>instead of "ruby-c" or "python-c"?? (well.. you know what I mean even if
>the terms are all wrong :) )

Yes. There might be a thunking layer to allow either ruby or python c 
modules to be compiled for Parrot, but I'm neither guaranteeing that, nor 
the efficiency of it if it exists. (Perl 5's API will *not* be supported 
(and a great sigh of relief arose from most folks who've had to write perl 
extensions in C...)) If we can, great. If not, well...

>BTW, thanks dan for answering the other questions I asked :)

No problem--glad to answer anything I can.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[e-mail]                         have teddy bears and even
                                      teddy bears get drunk