Re: [Fwd: Re: more parrot-questions..]

On Fri, 2002-01-18 at 05:11, Dan Sugalski wrote:

 
> >Anyway.  I'm having some problems understanding how to inherit from a
> >base class so I would appreciate if you could answer at least that part
> >in the attached mail.
> 
> Will do. You won't like it. :)

You're right :)

[LOT'S OF STUFF CUT]

> >How far off in time is the "call_method"-parrot-op? When can we start
> >doing real implementations of the ruby-classes?
> 
> We need subroutines and packages to get it implemented. We need more 
> than that to do it efficiently, but that's all a SMOP.

SMOP?
 

> >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.
> 
> From that perspective, you're quite right. Depends, I suppose, on 
> whether you consider the object hierarchy a part of the language, a 
> part of the core library, or a quirk of implementation. For me, as 
> the engine designer, it's in the core library category.

I understand.  For me as a user of the language it's one of the things
that makes it so great and therefore very important. 
 
> >Personally I think the advantages of interaction between the languages
> >outweighs the disadvantages.
> 
> I think so too. :)
> 
> I think, in practice, that it won't be a problem, but then I'm 
> writing at what's essentially the assembly language level so my 
> viewpoint's a bit skewed.

:-)

> Also, this is only an issue with cross-language objects. If you stay 
> completely within Ruby code you'd never know.

It should be quite easy to "wrap" for example a ruby-class (with objects
and all) in ruby with minimal code-bloat. 

> >  > 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.
> 
> If you look at things right, perl really is completely OO. (You'll 
> need to stand on your head) For perl 6, it's much more so as part of 

I prefer to keep my feets on the ground instead of my head :)

> the language itself, and completely so for the implementation. Almost 
> completely by accident, but it was such a nice accident in terms of 
> performance that it's here to stay.
>
> >  > >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?
> 
> Some, but not much.
> 
> There's two bits here. The first are (as far as Parrot's concerned) 
> generic methods and such, which live in the class' namespace. They 
> get called with the call_method vtable, and we'll probably just do a 
> dynamic by-name lookup and indirect dispatch. Nothing fancy there at 
> the moment, though it can get fancier later. (Got some ideas and some 
> pointers at ways to optimize this sort of thing)
> 
> For the specific class of methods that Parrot considers 'core', or 
> the things that populate the vtable, there currently is no dynamic 
> inheritance. The vtables are populated with pointers to real 
> functions and that's it. Parrot'll keep a class hierarcy in, and 
> it'll know what's a child of what class. When you change a parent 
> class' methods such that its vtable changes, Parrot will 
> automatically refigure the vtable for the child classes (it's just an 
> array of function pointers after all) with pointers to the new 
> routine(s).
> 
> I'm going to go and set some of this stuff in wet concrete, BTW. I'd 
> not given the details a whole lot of thought until now.

So should I understand this as "it's not implemented yet but it will
rock once it is" ??

> >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?
> 
> The core datatypes the engine really cares about are platform 
> integers, platform floats, bignums (basically an indefinite-precision 
> base-10 number), and parrot strings.
> 
> Parrot strings are a character buffer combined with encoding, 
> character set, and locale information on the string. They're meant to 
> be programming-language neutral. (A Unicode string in UTF-32 with a 
> Finnish locale doesn't care whether it came from Perl, or Python, or 
> Ruby)

From parrots point of view I guess that's true.  But consider the
following code

=== PYTHON CODE =====
def python_method()
    return "foobar"

=== RUBY CODE ====
str = python_method()

==== END ====

From the ruby-codes point of view.  What is the python_method
returning?  If it's a string from pythons point of view one would use
str.upper() to convert it to uppercase.  If it's a string from rubys
point of view you should use str.upcase.

If I understand everything correctly the variable "str" will actually
hold a python-string and have to use pythons methods for working with
it. Is that correct????

What I'm asking is if it should make sence to convert between ruby's and
python's string-type (as an example).

> There's not actually a PerlString type as such--the PerlString class 
> is mis-named. It's a subtype of the perl scalar, for scalars that 
> currently have only a string in them. Since perl scalars can be 
> strings, integers, floats, or any number of other things, it makes 
> sense to have specialized subtypes for those cases where it has 
> *just* a string, or an integer, or a float. No need to check flags 
> that way, no need to test and branch, and thus no need to blow your 
> CPU pipeline a few times before you get to doing the real work.
> 
> I get the feeling the explanation's missing a bit, so prompt me for 
> the bits that are unclear and I'll explain better.

I think we are on two different levels here.  I'm looking at things from
a ruby's viewpoint and you are looking at it from parrot's.

/Erik

-- 
Erik B虍fors               | [e-mail]
Supporter of free software | GSM [phone]
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32