PMCs and Objects question
Klaas-Jan Stol
My question concerns functionality of PMCs and Objects.
while reading the docs about the functionality of classes and objects, I
read that the vtable entries of a class can be overridden to give the
class special behaviour. I'd like to know if I'm correct (I just
realized this), if I say that: you can give a variable the same
behaviour by either write it as a pmc, or as class. When giving the
functionality to a PMC, you write it in C, when doing it with a class,
you write it in PIR. Am I correct?
If so, why then would one ever want to write a PMC (maybe for speed?)
(for example, as a language implementer). My point is, you could also
override the vtable entries just in PIR, which is (in my opinion) a bit
easier to do. Add to that the advantage that you don't have to
distribute your language's PMC collection (FooInt, FooFloat, FooString,
etc.) but the only thing a user would need is the compiler.
Furthermore, if my assumption above is correct, then "morphing" and
stuff works the same way?
Thanks in advance,
klaas-jan
Leopold Toetsch
>
> hi,
>
> My question concerns functionality of PMCs and Objects.
>
> while reading the docs about the functionality of classes and objects, I
> read that the vtable entries of a class can be overridden to give the
> class special behaviour. I'd like to know if I'm correct (I just
> realized this), if I say that: you can give a variable the same
> behaviour by either write it as a pmc, or as class. When giving the
> functionality to a PMC, you write it in C, when doing it with a class,
> you write it in PIR. Am I correct?
Yes, you can implement almost everything a class needs inside a PIR
file. Have a look at languages/lisp for a PIR-ony implementation.
> If so, why then would one ever want to write a PMC (maybe for speed?)
Yep
> Furthermore, if my assumption above is correct, then "morphing" and
> stuff works the same way?
HLLs usually don't morph their objects. Instead new objects of the
desired type are returned. It's probably just perl with it's references
that needs morphing. Anyway messing with PMC internals isn't exposed,
you'd need e.g. call a NCI function to accomplish this task.
> Thanks in advance,
>
> klaas-jan
leo
Klaas-Jan Stol
> Klaas-Jan Stol wrote:
>
>>
>> hi,
>>
>> My question concerns functionality of PMCs and Objects.
>>
>> while reading the docs about the functionality of classes and
>> objects, I read that the vtable entries of a class can be overridden
>> to give the class special behaviour. I'd like to know if I'm correct
>> (I just realized this), if I say that: you can give a variable the
>> same behaviour by either write it as a pmc, or as class. When giving
>> the functionality to a PMC, you write it in C, when doing it with a
>> class, you write it in PIR. Am I correct?
>
>
> Yes, you can implement almost everything a class needs inside a PIR
> file. Have a look at languages/lisp for a PIR-ony implementation.
>
If I understand correctly, the object system and the PMC types are very
much related. I read that when creating a new class, then a new
ParrotClass is created. (ParrotObject is the PMC that takes care of the
implementation of a run-time object in Parrot, right?). But, a new class
can inherit from a built-in PMC type, right?
I try to understand the difference between PMCs and user-defined classes.
>> If so, why then would one ever want to write a PMC (maybe for speed?)
>
>
> Yep
>
>> Furthermore, if my assumption above is correct, then "morphing" and
>> stuff works the same way?
>
>
> HLLs usually don't morph their objects. Instead new objects of the
> desired type are returned. It's probably just perl with it's
> references that needs morphing. Anyway messing with PMC internals
> isn't exposed, you'd need e.g. call a NCI function to accomplish this
> task.
I meant (but I think I got your point of returning an object of the
desired type), suppose the Perl datatypes were not implemented as PMCs
but rather as user-defined classes (written in PIR). So:
# Let's assume there are no PMC's at all, not even the built-in Integer
and Float (and others),
# otherwise we could just as well inherit the Integer PMC, if I'm
correct (and then no attribute "value" were needed)
#
# define a new class
class $P0, "PerlInt"
addattribute $P0, "value"
# define the methods for this class
.namespace ["PerlInt"]
.sub __set_integer_native method
.param int i
# set "value" attribute of this object to i's value
.end
This would work too, right? In fact, suppose all methods that are
implemented for the PerlInt PMC were written as methods in the PerlInt
class' namespace, like above, the system would behave exactly the same
way, right? (except, of course, it's not as fast). In fact, suppose
there were not built-in PMC's at all (of course, there has to be
something implementing the object system, now done by ParrotClass if I
understand correctly), but all these types were written in PIR (also the
hash pmc's), then the system, again except for speed, would behave just
the same, right?
klaas-jan
Chip Salzenberg
> I read that when creating a new class, then a new ParrotClass is
> created. (ParrotObject is the PMC that takes care of the
> implementation of a run-time object in Parrot, right?). But, a new
> class can inherit from a built-in PMC type, right?
Yes, there's a PMC inheritance mechanism that works for things that
wouldn't be called "classes" in Perl 6. For example, PerlUndef is a
PMC that's derived from PerlInt. (Someday, I hope to know why.)
> suppose the Perl datatypes were not implemented as PMCs but rather
> as user-defined classes (written in PIR). [...] This would work
> too, right?
I think so, though I imagine it would be a bit of work to make sure
the ParrotObjects were actually complying 100% with the API provided
by the current PMCs.
I can imagine that for debugging purposes -- or maybe just for the
sheer fun of it -- someone will eventually try it.
--
Chip Salzenberg <ch...@pobox.com>