Alek Storm wrote:
I've asked for something pretty darn close to what you've suggested
(see #41619), but you've explained it a lot better than I ever could.
Glad we're thinking similar things.
What I think you were saying:
Default
|
BaseClass (default Parrot implementation)
/ \
Class UserClass
(PCCMETHOD interface to BaseClass) (modified version of BaseClass)
Please correct me where I'm wrong :)
Yes, though maybe I'd not say "modified version of BaseClass", but
"inherits from and extends BaseClass" or something.
Instead of having a BaseClass, which I think would be an unnecessary
layer of indirection, PMCs implementing class behavior should be able
to inherit from either:
1. Default: Throw an exception if an unimplemented vtable method is
called on the PMC.
2. ParrotClass: All semantics are already taken care of, and you need
only change the behavior where necessary.
The choice of which to inherit from is left up to the PMC implementor.
I think, naming of it all aside, we agree here. I said in my email:
~~
HLL implementers who need their own class PMC but can implement it in
terms of the BaseClass semantics can then derive from BaseClass.
~~
Or put another way:
* If you want, inherit from Default and build from scratch.
* If [insert name of the thing that just has the vtable methods here]
gives the right semantics to build upon, inherit from that.
* If [insert name of the thing that also provides the nice sane
interface here] is what you want and you just want to add to it a bit,
inherit from that.
Or more generally, inherit from whatever leads to the least code
duplication and gives the interface you want. :-)
We could also add "class" to the list of do-able interfaces available
to PMCs in tools/build/pmc2c.pl.
Aye, we could, though we already have the "I am a class" flag. I don't
think having two different ways to specify or check if something is a
class is a good thing.
Jonathan
