On Jul 27, 2005, at 4:00 PM, Klaas-Jan Stol wrote:
hi,
Is there any documentation about the complete syntax for pmc files
when writing PMCs (this time in C)?
I think that's technically the only way to write PMCs. (things
written in PIR are Objects). And, as you've seen, pmc2c.pl is
currently where most of this documentation lives.
I found genclass.pl and pmc2c.pl, but I couldn't find anything
about all keywords that can be used. In particular, I wrote down
some scenarios. Maybe there are some more cases than these.
Case 1:
pmclass Foo {
[ vtable methods here]
}
This one is simple. It just creates a new PMC class, as a
superclass. If I understand correctly, when writing such a class,
you would start with genclass.pl. Or, would extending "default" be
ok as well?
A note: genclass gives you a PMC with a *lot* of empty methods. You
should delete all the ones that you don't actually want to override.
You don't need to extend default, that's the default if you don't
override something.
Also note that you can put in methods that don't correspond to vtables.
Case 2:
pmclass Foo extends Bar {
[vtable methods here]
}
A PMC class extending from Bar. Extra vtable methods for Bar's
extra functionality (WRT Foo), or vtable methods with different
behaviour than Bar, must be written.
Yup. Note that you can specify multiple extendees.
Case 3:
pmclass Foo does Bar {
[vtable methods here]
}
I don't really understand what this does. I understand the "does"
keyword says something about an interface ("Bar") that is
implemented by this class ("Foo"). Why would you do this? Why does
one need this? I saw in pmc2cl.pl that there are a number of
interfaces defined already. Is there anything written about these
interfaces?
Does corresponds to the C<does> opcode: there's no formal definition
of these interfaces, so there's no concrete list: it's only a
convention at this point. pmc2c.pl has a fairly recent list of what's
in play, and I've updated the POD to reflect these comments below
(some of which are WAGs).
array : container PMC with numerically-keyed elements
event : PMC that can be used with event queue
hash : container PMC with string-keyed elements
library : PMC that corresponds to a dynamic library
ref : PMC that references another PMC
scalar : (only used by the sample dynclasses/foo.pmc)
I'm guessing scalar might correspond directly to things Integer,
String, PerlNum, but no one is using that at the moment.
So, to sum up: when you use does in your PMC, you're not actually
contractually obligated to say that the PMC is going to act a certain
way; so, when I use does in my PASM, I'm not guaranteed anything
other than that you put that keyword in your PMC def.
Regards.