On Monday 30 July 2001 07:07 pm, Dan Sugalski wrote:
> FWIW, the interpreter will treat the following three things (Barring
> changes from Larry) as composing a unique identifier:
>     Module Name
>     Author
>     Version

I originally said I thought choosing by author to be a bad choice.  I've 
changed my mind.  (I realized that authors doesn't necessarily equate to 

> You'll be able to wildcard author and version, as well as specify a range.
> Version numbers won't be capped at x.99--they'll continue on indefinitely.
> We may also have an alpha/beta/release flag, but that's not certain.

I'd encourage it.  The rest of the information is complicated enough, that 
two more flags are insignificant compared to the gains of being able to tel 
with all certitude the maturity level of the code.  (Albeit, as reported by 
the author.)

> When you actually use a module, the simple name (like IO) will be
> internally expanded out to the three value thing. So if you have two
> modules that each use a different version of the same module, they won't
> interact because each will be dealing with a separate thing.

And *that* is the real trick, now isn't it?

> The interpreter will also alias one of the exported 'full' module names
> as  the simple name. So, while the real namspace for IO might be
> IO$CORE$1.02, say, it'll also be seen as plain IO. (Which one gets
> exported this way when multiple modules are used is rather up in the air.
> I don't have the answer at the moment.

To throw out other things that have been discussed on high, there was even 
some discussion on the possibililty of modules (and potentially the symbols 
they export) being introduced into the calling code lexically.  If that is 
the case, then you needn't worry about the exporting or the code collision.  
Unless you do something bad.  The only real difference is that you can 
unexport, and essential pop the lexicals before end-of-scope.

Bryan C. Warnock

Reply via email to