Re: Module naming and identification

On Apr 9, 2009, at 20:40, [email protected] wrote:

> Hi folks,
>
> Kris Kowal and I have been thinking about modules in JavaScript a  
> lot. :) Our current proposal (which should be unsurprising to this  
> list) contains a loader which turns module identifiers into maker  
> functions, which can then be instantiated with some capabilities.  
> (For the current stage of our proposal, it is wrapped in a  
> "require()" function that uses a "sandbox" abstraction, but this  
> fact may be safely ignored because it is just a thin layer on top of  
> maker functions.)
>
> So far, we have left somewhat open the question of the syntax and  
> semantics of module identifiers. This document, with lots of help  
> from Kris and MarkM, is an attempt to address this question a bit:
>
>   http://docs.google.com/Doc?id=dfgxb7gk_61d47876fr
>
> Comments welcome as always.

- The notion of naming modules with URIs is good. It would be better  
if there was a standardized URI-which-designates-the-data-with-this- 
hash -- this would fulfill the use case of "avoid code duplication,  
but don't specifically rely on anybody else's server or have to change  
the identifier to point at my server".


- Your use of "local names" is confusing to me. I think there are  
three namespaces at issue here:

    1. The names by which "this program/module" refers to other  
modules. These are lambda names, in our terminology.

    2. The URI of a "package" -- a global name.

    3. An name identifying a "module" within a given "package".

You seem to use the term "local name" for both 1 and 3. Just as you  
point out that Perl/Python style module systems conflate these, I  
think you should establish clearly distinct terms for them.


- Other than this, your design seems quite nicely similar to the one  
in my head that I've been meaning to implement for E -- except that  
you call a "package" what I call a "module", and your "modules" would  
then be my individual objects in a module. Are your "modules"  
namespaces of application-specific objects, or are they such objects  
themselves?

(These "application-specific objects" would be such things as makeFoo  
functions in an E system.)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>