allison replaced the .IMPORT macro, used for importing pmcs into the
current namespace, with the namespace 'export_to' method defined in
PDD21. however, this code is lacking in safety guards (eg. what if the
foreign namespace doesn't exist?) rather than adding that check to all
code, i'd prefer to see an Exporter PMC that defines an api for
exporting.
not only would this set a standard api for export operations, but it
would allow a user to override behavior of the default exporter by
subclassing.
~jerry
Proposed interface:
$P0 = new Exporter
$P0.import($P1, ['KeyTo'; 'ImportedNamespace'], $P2)
where $P1 is the current namespace, and $P2 is an array of sub names to
import. It'd be even better if we could have the method detect the
namespace of its caller, rather than having to pass it in manually.
Likely we'll eventually want functionality along the lines of Perl 5's
@EXPORT, @EXPORT_OK, and %EXPORT_TAGS (with some more Parroty interface
to the features).
Allison
Could we also do some multi-dispatch here or typechecking of $P2
so that it could also be a whitespace-separated string of subnames
to import? Then instead of
$P2 = split ' ', 'foo bar baz'
$P0.'import'($P1, ['ImportedNameSpace'], $P2)
we could write
$P0.'import'($P1, ['KeyTo'; 'ImportedNamespace'], 'foo bar baz')
It also helps in the case where we only want to import a single
symbol.
> It'd be even better if we could have the method detect the
> namespace of its caller, rather than having to pass it in manually.
I believe there was a way to do this (using interpinfo), and
I agree that it would be much better. And perhaps it could then
be an optional named parameter, so that we import into the
caller's namespace by default, but there's an option to
import to another explicit namespace.
Pm
> On Sat, Mar 17, 2007 at 12:12:12PM -0700, Allison Randal via RT wrote:
>> Jerry Gay (via RT) wrote:
>>> ...an Exporter PMC that defines an api for
>>> exporting.
>>
>> Proposed interface:
>>
>> $P0 = new Exporter
>> $P0.import($P1, ['KeyTo'; 'ImportedNamespace'], $P2)
>>
>> where $P1 is the current namespace, and $P2 is an array of sub
>> names to
>> import.
>
> Could we also do some multi-dispatch here or typechecking of $P2
> so that it could also be a whitespace-separated string of subnames
> to import? Then instead of
>
> $P2 = split ' ', 'foo bar baz'
> $P0.'import'($P1, ['ImportedNameSpace'], $P2)
>
> we could write
>
> $P0.'import'($P1, ['KeyTo'; 'ImportedNamespace'], 'foo bar baz')
>
Ok, but then how would import the sub, "foo bar baz"? ^_^
> It also helps in the case where we only want to import a single
> symbol.
>
>> It'd be even better if we could have the method detect the
>> namespace of its caller, rather than having to pass it in manually.
>
> I believe there was a way to do this (using interpinfo), and
> I agree that it would be much better. And perhaps it could then
> be an optional named parameter, so that we import into the
> caller's namespace by default, but there's an option to
> import to another explicit namespace.
>
> Pm
>
--
Will "Coke" Coleda
wi...@coleda.com
With:
$P2 = new .ResizablePMCArray
push $P2, 'foo bar baz'
$P0.'import'($P1, ['KeyTo'; 'ImportedNamespace'], $P2)
Subs with spaces in the name are the rare case, so it's okay
if a PIR programmer has to do a little extra work for those. :-)
And silicon-based PIR generators would likely be generating the
array anyway, or otherwise dealing with the case of a delimited
list of sub names.
Pm
+1
>> Ok, but then how would import the sub, "foo bar baz"? ^_^
>
> With:
>
> $P2 = new .ResizablePMCArray
> push $P2, 'foo bar baz'
> $P0.'import'($P1, ['KeyTo'; 'ImportedNamespace'], $P2)
+1
Allison