[EMAIL PROTECTED] wrote:
Hi,
After a while away I'm starting to get back into Parrot. I've been reading
PDD17 and like what I'm seeing - nice work. :-) I'm trying to get it and
the current state of its implementation into my head, so I can help out
with it. It appears there is much left to implement!
Implementation isn't started yet. PDD 17 is scheduled for stub
implementation Jan 1.
I've got a couple of questions (or requests for clarification) so far.
1) Looking at the definition of role composition, it looks a little
different to what I had expected.
"Composed vtable functions, methods, and attributes are not permitted to
have the same name as corresponding features defined in the composing PMC.
This is called a conflict, and must be explicitly resolved in the
composing PMC."
a) I guess this should mention that if two roles have a
[vtable|method|attribute] of the same name then that is a conflict that
needs to be resolved too?
Yes.
b) What should the syntax and semantics for the resolution mechanism be?
Add a few keywords to the pmclass/prole line. Best to keep it as similar
as possible to high-level role conflict resolution, so 'resolves',
'excludes', 'alias'. The syntax is more complex than the simple
keyword/value pair common to other pmclass modifiers, since it needs to
specify the name of the relevant role, and whether it's resolving a
vtable/method/attribute.
Is anyone working on the proles stuff yet? Maybe that's something I can
dig in to.
AFAIK, no one is working on it at the moment.
2) In the defining attributes section it is written:
"The declaration is also used to generate accessor macros for the class,
in the form of GET_ATTR_<attrname> and SET_ATTR_<attrname>"
However, in the PMCs and high level objects section it says:
"It will also override the GET_ATTR_attrname and SET_ATTR_attrname
functions to point to the PDD 15 attributes (with automatic boxing and
unboxing for the PMC values) rather than to members of a C struct."
They can't simultaneously be macros and functions. :-) I guess they will
have to be functions, hung off somewhere so we can change the over to the
version that gets at the PDD15 attribute? Where is that somewhere?
Ah, the two sections caught two different stages of design-in-progress.
There are two basic design goals here: to provide an appropriately brief
syntax for attribute access within the C code for PMCs, and to allow
high-level classes that inherit from low-level PMCs to correctly access
high-level data storage from within inherited methods and vtable
functions (instead of accessing the low-level data storage).
The simplest approach to the first goal is a set of macros, but the
simplest approach to the second goal is to use the 'get_attr_str' and
'set_attr_str' vtable entries. Likely the best solution is to generate
the GET_ATTR_<attrname> and SET_ATTR_<attrname> macros, which resolve to
vtable calls to 'get_attr_str' and 'set_attr_str'.
If there's anything I should specifically work on that is blocking folks,
please let me know. I can't promise I'll get to everything in a hurry, but
I should have time to actually do some Parrot stuff again now.
Completing the new bytecode implementation is also important. It's not
due until Feb 1st, so this has a higher priority, but time-sharing
between the two (or delegating pieces of the bytecode implementation to
others) would be ideal.
My current implementation focus is Events (due Dec 1st), but I'll shift
to PDD 17 after that.
Allison
