Front page | perl.perl6.stdlib |
Postings from June 2002
At 07:49 PM 6/16/02 -0400, Uri Guttman wrote:
> JS> But what if they use Local:: and then want to use someone else's
> JS> Local:: modules? (Say they purchased another company or are
> JS> partnering with someone.) What if they want to release their code
> JS> to CPAN, despite the fact that it may still be vendor-specific?
> JS> (e.g. a parser for Acme's electronic widget order receipt or
> JS> something.) I think there are real problems to be solved here.
>
>one idea i have seen but could be formalized is a way to load a module
>which is named Foo::Bar and have it not affect the actual current symbol
>tables. instead another namespace is installed which maps to the loaded
>file's space. that module could be loaded as Local::Foo::Bar. all
>mentions of Foo::Bar in that module are changed (compile or runtime?)
Both, surely? Need to handle "my Foo::bar $spot" and also evals.
>to
>the newly mapped namespace. so you can do module space renaming/aliasing
>at load time. this doesn't solve the issue with stopping or managing
>collisions but it allows any application to work around them.
It would be nice if one could say
use Foo::Bar as Local::Foo::Bar
as a way of expressing your proposal. But if some run-time code generates
and evals a reference to "Foo::Bar", how can Perl know which one it
means...? Since presumably the reason for remapping in the first place was
so that you could use another Foo::Bar? If you say that the renaming
applies to all code in what is now Local::Foo::Bar, you also have to do it
to every module that is used by it, which may end up including a module
that is also used by the Foo::Bar that you want to actually refer to that
way? Well, okay, perhaps that's weird enough that you could barf if it
happens.
So every piece of code might end up having a mapping table associated with
it to be consulted any time a reference to a module was generated at run-time?
--
Peter Scott
Pacific Systems Design Technologies
Thread Previous
|
Thread Next