Yes, this makes sense and makes it almost trivial to map Ruby's object
system. Your __resolve__ would be Ruby's method_missing, basically. In
general, I think it would be a good thing for Neko to support a
rudimentary prototype-based oo system since most OO systems can be
modeled on top of that.
I was already thinking about it, but it's not very easy choice.
I don't want to introduce a second kind of object so it means adding an
additional table to each object storing it's prototype. The prototype
would be an object itself, and they would be chained :
classA = { f => function() };
instA = $new(null);
$setproto(instA,classA);
classB = { g => function() };
$setproto(classB,classA); // B extends A
instB = $new(null);
$setproto(instB,classB);
That's pretty easy to implement, but require an additional 4 bytes per
object (currently only 8 bytes per object), and also it prevents
implementing a powerful cache technic I'm thinking for JIT. OTOH, shared
prototypes can reduce memory footprint... Not yet sure what is best.
Before seeing your proposal I toyed around with using MethodContext's
(mc in code below) with a rolled out version of the class hierarchy in
each MC. Turns out a core for the Ruby OO system can be done in 50-100
lines of Neko in this way. However, handling Ruby's method_missing
would mean adding a handler for that to each "unused" method field in
each MC which would work but be kind of awkward. Also with this
solution interoperability is hard of course. However, it allows the
following Ruby code:
Yes.
I think that you should go this way right now and later when I add
"resolve method" that will simplify and speedup the generated code.
Nicolas
---
Neko : One VM to run them all
