Re: [Cardinal-dev] RubyInRuby parser/compiler

[Erik Bågfors]

On Fri, 2003-01-03 at 23:36, Dan Sugalski wrote:

> >>  I bet it's more like:
> >>
> >>  * Add constant 1 and constant 2
> >>  * Put the result into a
> >
> >Well.. what happens if we have the following code then??
> >
> >class Fixnum
> >   def +(val)
> >     puts val
> >   end
> >end
> >
> >a=1+2
> >
> >that will acctually output "2" in ruby.  How can that be done without
> >creating objects and looking up the "+"-method??
> 
> Oh, you do. While the addition is of two constants, they're ruby 
> integer constants, with whatever behaviour is appropriate for them, 
> so the Fixnum addition method will get called. (I assume Ruby doesn't 
> do constant folding)

Don't know about constant folding...


> >>  >Anyway, I really feel that we can't do very much more than play with
> >>  >compilers/pmcs/whatever until parrot has real object support.  Ruby is a
> >>  >very oo language :)
> >>
> >>  Soon. By next thursday.
> >
> >Really?? That's too cool :)
> 
> Heh. Now I just have to follow through. :)

Guess who will bug you on thursday  :)

> Ah, but in the Parrot case, this is universally:
> 
>    b->vtable->add(b, c, a)
> 
> All the overloadable operators have a slot in the PMC vtable. Each 
> language has its own name to vtable slot mapping for its classes, so 
> when you add a method that matches the language's overload list, it 
> fills in the right vtable slot.


Ok, but what happens to language-level objects. I assume that all
objects are not PMC's? And vtables are only for PMC's right? (as you can
see I know too little about this)


> >But can you override methods in a pmc anytime?  I thought PMCs where
> >somewhat static.  Also, can you add methods to a PMC?  Will PMC's be the
> >only objects that exists in parrot?
> 
> You can change the vtable methods in a PMC's class at any time. 
> There's a 1-to-1 mapping of language classes to PMC classes.
> 
> Also, don't confuse vtable methods with general object methods. 
> vtable methods are a fixed set of methods that we cache for speed 
> reasons, while general object methods are looed up in a more general 
> but slower way. It's a speed thing. :)

Makes perfect sense. 

> >I think I'm missing out on something obvious since Dan seams to have a
> >different view on things (and he knows parrot alot better than I do :) )
> 
> I think I'm not explaining things well. I better put together a 
> bigger document on this.

Wait until the "normal" objects are in parrot.  Then I'd love a document
on this :)

/Erik

-- 
Erik Bågfors               | address@hidden
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32