Jonathan Worthington wrote:
All that said, there is an argument for having it as a vtable method
that I think stands, which is the same argument that suggests not having
any methods on the class PMC at all and making everything a vtable
method. The argument is that if a language wants to inherit from the
Class PMC, it may well want its own names for "add_attribute" and so on.
That'd mean a few new vtable slots for add_role, methods (get list of
methods), attributes (get list of attributes), roles (get list of roles)
and parents (get list of parents).
We've got add_method, add_attribute, add_parent, add_role (note, these
are confusingly named next to add, add_int, and add_float), get_class,
get_attr, set_attr, find_method, clone, isa, can, does specified as
vtable entries.
What would be remaining is removes for parents/attributes/roles,
introspection for methods/parents/attributes/roles, name, new, newclass,
subclass.
- newclass is just syntactic sugar for 'new', so doesn't get its own
vtable entry
- There's too much confusion around 'new' so I'll suggest 'instantiate'
(which was an opcode in an earlier draft, and has been implemented and
deleted at various times over the history of Parrot).
- Does 'subclass' make sense as a vtable entry? "Make a subclass of
yourself." No, let's leave it at 'add_parent' on the child class.
- For removes, let's go with 'remove_*' for parent/attribute/role.
- For now let's say you can't set the 'name' on an instantiated class,
but only through the initialization parameters of a class. (And
re-evaluate if it turns out we need the feature later. We may also need
to consider how to modify clones.)
- I'm inclined not to provide individual named vtable entries for
introspecting the methods/parents/attributes/roles/name information of
the class, because once we start down that road we'll be providing
hundreds of named vtable entries for introspecting various different
classes and PMCs, which is just insane. Instead, I'd like to provide one
general introspection vtable entry, which each class/PMC can implement
how it chooses. Suggestions welcome. I'll start with: 'inspect', which
when called with no arguments returns a data structure of all
information it considers relevant to report, and when called with a
string name ('attributes', for example, or 'name'), returns a PMC Hash,
Array, String, Integer, or Number value corresponding to the requested
name. This may be overridden to report information about the internals
of an object that aren't actually true (useful for mocking). It can also
be used for straight introspection capabilities even when a particular
object is using keyed access to act like a hash or array.
Unfortunately, going down that route leaves us with only being able to
use the C calling conventions rather than being able to provide a nice
interface to the OO system as we can by making those things PCCMETHODs.
There is a compromise - make them all vtable methods, write a BaseClass
PMC and inherit Class from it. BaseClass implements all of the vtable
variants of the method, and Class can then provide a sane interface. HLL
implementers who need their own class PMC but can implement it in terms
of the BaseClass semantics can then derive from BaseClass. (Oh, and I
think BaseClass is totally the wrong name, but I know Allison will find
a good name too... ;-))
Class is the base for all classes. I can see the value of stripping away
any methods that may interfere with a particular HLL's concept of how a
class should behave, so we'll do that. And what should we call the
subclass of Class that adds lots of methody syntactic sugar over the
top? My best suggestion at the moment is ParrotClass, as a contrast to
PerlClass, PythonClass, RubyClass, etc.
Allison
