hi,
Will Coleda wrote:
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.
yep, thanks. In a previous posting (or blog entry? I can't find it at
this moment), I think Dan mentioned that "the plan" was to be able to
write PMCs either in PIR or in C. Depending on the server running
Parrot, one of both implementations would be used; sometimes it may not
be possible to have you own custom PMCs installed, so you would have to
use the PIR version.
But you're right, creating PMCs in PIR uses the newclass/subclass
syntax, which makes them objects. But, if I understood correctly, they
behave more or less the same, right? (in that case, effectively it
wouldn't make any difference)
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.
You mean, this is done implicitly, right? (in Java terms: writing a
"class Foo { ... }" would mean Foo is extending "Object")
Also note that you can put in methods that don't correspond to vtables.
These would be called as... ehm... "methods" :-), right?
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.
I don't know very much about multiple inheritance, but I do know a bit
of C++ (not very fluently); what if you would inherit from 2 classes
that both offer the same method?
Which one is called? (I think C++ just won't compile, but it's been some
time I used it)
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.
This will change later, right? Otherwise your PMC could be lying, saying
it *does* something, which it doesn't.
Regards.
I came across another thing WRT PMC writing singleton.
Suppose I would want to have my own custom representation of "None". I
created a class extending None, but this child class is no singleton
anymore (I created 2 instances, compared them: they proved to be 2
different objects). Looking in none.pmc:
INTVAL is_equal(PMC* other) {
MMD_None: {
return 1;
}
MMD_DEFAULT: {
return 0;
}
}
}
What should I do to have my child class be a singleton too? (just
extending singleton as well?)
thanks for your help,
klaas-jan
