Let's not throw this out completely. Let's explore the possiblities.
Making a module local to the using package, might have interesting
properties.
The only items of interest are the globals. And by making them visible
(or a version visible) to the use-ing module, two modules can get
different behaviours without stomping on each other.
All the isolation that we're developing for threads would help this out.
So the used package's globals can be lexically scoped in the user.
The only breakage that I see, is having some way of globally setting
a variable. For example, turning on debugging for all uses. (FTP::Debug
I find quite popular.)
Can anyone see any other breakage?
<chaim>
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It'll happen at least once.
DS> I suppose we could go insane and make packages loaded in through modules
DS> completely invisible to all but the use-ing package, so in this case main
DS> wouldn't even know there was a C loaded, and if it tries to mess with
DS> things in the C package it gets its own empty stash to deal with. (Which
DS> all other packages that didn't use one version of the module or another get)
DS> I suppose that's a fancy way of saying namespaces created by used modules
DS> are private to the package using them. (Though that still leaves the issue
DS> of what happens when package B uses something from package C which wasn't
DS> created on the use, but then I'd probably just say "you get your version of
DS> C. Nyah!")
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
