Leopold Toetsch wrote:
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
