Paul Johnson wrote:
> > > > Note that it may not be possible to satisfy conflicting requests.
If
> > > > module C<A> and module C<B> demand two different versions of the
same
> > > > module C<C>, the compiler should halt and state the module
conflicts.
> > >
> > > Pardon me for sniping at a great RFC, but I already promised the CPAN
> > > workers that I'd make that last statement false. There's no reason in
> > > principle why two modules shouldn't be allowed to have their own view
> > > of reality. Just because you write Foo::bar in your module doesn't
mean
> > > that Perl can't know which version of Foo:: you mean.
>
> Has anyone considered the problems associated with XS code, or whatever
> its replacement is?
>
The big problem about having more than one version of a module loaded at the
same time is with namespaces, because the same namespace is actually used by
more than one (version of) module. In Perl code, this will probably be
defined when the module is `use'd, and all access to the namespace provided
by the module will be issued to that version of the module.
In C low level code, we'll probably won't have how to magically use a
specific version of a specific module for all the XS code, so I think we'll
probably have to say on each namespace access, which module version we are
accessing, ie. instead of
SV *sv = perl_get_sv("package::varname", FALSE);
we'll probably will have to include the version of "package" that is loaded:
SV *sv = perl_get_sv("package::varname", FALSE, 2.35);
I see a problem here when `use MyModule' creates namespaces MyModule,
MyModule::InternalModule, MyModule::OtherModule, etc. and mainly when `use
MyModule' creates namespace OtherNamespace (that has nothing to do with the
name `MyModule'). How will Perl know what's the version of the module
associated with OtherNamespace ??? What if several modules put things in a
common namespace ?
- Branden
