Brent Dax wrote:
> # I'm a bit confused as to how one creates a user-defined class
> # in Parrot, and makes virtual method calls, accesses fields,
> # and what-not. I can't seem to find a good example (Cola does
> # non-virtual methods only at present).
>
> You don't, at least not yet. Eventually, there'll be an Object PMC
> (which can be inherited from to make PerlObject, CsObject, etc.); to
> retrieve a method, you'd probably call something like
> getmethod(methname) on the Object, then push your arguments onto the
> stack and call invoke() on the Sub (PerlSub, CsMethod (no subs,
> right?)...) PMC getmethod() gave you.
Seems reasonable. For the time being, I can jury-rig something
with PerlHash PMC's, and plug in the "real deal" when it is available.
> For a multimethod subroutine, the
> Sub PMC would look at the types of the arguments on the stack and choose
> which routine to invoke; for a normal subroutine, it would just invoke
> the code. Presumably, the C# compiler could optimize that further.
My compiler already knows which variant to call, so multimethods
wouldn't be much use to me (they might be for other languages).
It would be easier for me to do getmethod("int foo(Object)")
instead of getmethod("foo") and a multimethod invoke().
> Oh, by the way, that's all speculation until Dan Sugalski specs it out.
Of course.
> # We in DotGNU should be able to bang out C#->Parrot fairly
> # quickly, if we can resolve the above issues.
>
> Please remember that Parrot is very much a work in progress. We've done
> a lot in the one year, one month and one week (really!) since we
> released, but we still have a lot to do before it's really usable for
> full languages.
I understand, as Portable.NET is also a work in progress. My hope
is that the two projects can help each other. Certainly, cscc should
be able to "torture the Parrot" from a non-scripting angle, which
will be invaluable for helping it evolve stronger feathers. :-)
Cheers,
Rhys.
