Namespace.get_namespace() vs. optional params
Chip Salzenberg
that, right now, if a method is written in C, it can't have optional
arguments. (This is per Leo; I haven't checked into how/why this
restriction arose.)
Thus, to support both of these interfaces:
=item get_namespace
$P1 = $P2.get_namespace($P3)
+ $P1 = $P2.get_namespace()
We'll have to either write the method in PIR (which isn't necessarily a
problem, though it will be a hair slower) or switch to MMD (I don't know yet
what that will do; for all I know it'll work perfectly the first time, but
it's just another thing to do as part of the conversion).
Mind you, I'm OK with this, but it's something to be aware of.
--
Chip Salzenberg <ch...@pobox.com>
Allison Randal
> Looking over the recent editorial improvements in pdd21, I need to point out
> that, right now, if a method is written in C, it can't have optional
> arguments. (This is per Leo; I haven't checked into how/why this
> restriction arose.)
Aye. This went through my mind as I made the change, but I decided to
add it anyway. Thinking through the chain of dependencies, though, I've
removed it again.
Long-term, we need to minimize the differences between low-level PMCs
and Parrot objects defined in PIR code. That may mean allowing optional
arguments and named parameter passing. But, I want to keep the PDDs
focused on driving us toward a 1.0 release, and this isn't a necessary
feature.
Let the yaks go unshaved,
Allison
Chip Salzenberg
> Long-term, we need to minimize the differences between low-level PMCs
> and Parrot objects defined in PIR code. That may mean allowing optional
> arguments and named parameter passing. But, I want to keep the PDDs
> focused on driving us toward a 1.0 release, and this isn't a necessary
> feature.
I've added a TODO ticket, in case somebody with spare tuits wanders by.
> Let the yaks go unshaved,
> Allison
It is not I who am crazy -- it is I who am _mad_!
--
Chip Salzenberg <ch...@pobox.com>