Root-relative namespace keys
Bob Rogers
rogers-perl6 at rgrjr.dyndns.org
Sun Jan 11 01:26:06 UTC 2009
From: chromatic <chromatic at wgz.org>
Date: Sat, 10 Jan 2009 16:34:35 -0800
On Tuesday 06 January 2009 22:57:22 Allison Randal wrote:
> We already have a consistent system for annotating sub parameters, so I
> have a hard time justifying inventing a new one. Because of this, the
> most compelling idea to me was to make :multi a no-argument modifier to
> .sub, and put the MMD decoration on the .params. We could make that
> consistent with class lookups by using the same key names:
>
> .sub 'blah' :multi
> .param pmc 'thingy' :hll('lang') :namespace('my') :name('foo')
I don't like the :namespace separation; we don't use it anywhere
else. With that said, I'm coming around to this approach. It's more
difficult to skim Sub signatures, but it doesn't cram as much
information into a single element, and it's easier to see the
important parts without ambiguity.
How about APIs to read/write this annotation? In particular, I would
like to see an introspection API to find out what classes this thing
specializes on, and a creation API to turn an "ordinary" sub and a
vector of classes into something that could be added as a component of a
multisub. The latter will be necessary for supporting anonymous
classes, seems to me.
Life is going to suck somewhat for the poor fool who has to patch
IMCC to make this work, though.
;-} Which could be an argument for relegating the hairier cases to a
:load sub that constructs the right class vector before adding the sub,
similarly to what we do now for superclasses.
> We'll also need an annotation for "does this parameter participate in
> MMD?" or maybe for "this parameter doesn't participate in MMD",
> depending on which is more common.
Exactly.
-- c
Is there a difference between "this parameter does not participate in
MMD" and "this parameter participates in MMD and is specialized to type
'Any'" [1]? If so, what?
TIA,
-- Bob Rogers
http://www.rgrjr.com/
[1] Or "_", or "Whatever". Or whatever.
More information about the parrot-dev
mailing list