Re: more parrot-questions..

On Thu, 2002-01-03 at 23:14, Dan Sugalski wrote:
> 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"

And here I can show my ignorance again by not knowing what the "seventh
lexical in the current scope" means :)

How far off in time is the "call_method"-parrot-op? When can we start
doing real implementations of the ruby-classes?

> 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.

Sounds good.

> >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.

According to what you write below, not really..
Sure, we can use the object like it was a ruby-object but it's not
really a ruby-object since it doesn't inherit from Object.

If I add a method to the Object-class it will not be in
python/perl-objects which means we are not really running in a
ruby-world.

Personally I think the advantages of interaction between the languages
outweighs the disadvantages.

> >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)

I don't think that is going to happen since perl is not really object
oriented at all (sure you can have object but still :) ), python is
half-way OO (some things are not objects/classes) and ruby is fully OO. 
There is no way to do this without turning perl and python into
something alot more like ruby or turning ruby into something other than
ruby.

> >BTW, thanks dan for answering the other questions I asked :)
> 
> No problem--glad to answer anything I can.

Good,  Then I'm giving you some more questions now :)

I been messing around with parrot alot lately and it's really really
really cool.  I WANT ruby running under this so I was thinking about
starting the whole thing.  I implemented a small RubyObject-pmc. This
was really easy since there was lot's of examples to build on.  A
RubyString, RubyNumeric, RubyInteger, RubyFloat and a few others should
also be real easy to create but I didn't find any good information how
to inherit from the RubyObject type.  There wasn't any documentation and
no examples but since there is a default class that can be inherited
from I guess it's implemented somehow. You have more info for me?

Writing as much of the ruby-implementation as possible in ruby itself
would of course be very cool.  The obvious way of doing this is to write
some objects and methods in c and then write the rest in ruby and
compile that ruby-code into parrot bytecode, then include that bytecode
into every ruby-program.  Of course this will not be as fast as a
c-version of everything.  I saw that there is a pbc2c-converter in the
parrot distribution.  Would it be possible to use this to "get the best
of both worlds"?  That is, the ruby language but the c-speed?

Will there be some way of automatic convertion between types??  What I
mean is this, let's say you have this wonderfull function in perl that
takes a PerlString and returns another PerlString.  I want to use this
from ruby and would really like to have RubyStrings for everything. 
Would automatic conversion between these types be something that's
good/possible?
 
Thanks again for your interest in ruby.

/Erik 
 
-- 
Erik B虍fors               | http://www.ardendo.se/
[e-mail]    | GSM [phone]
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32