module exports

David Herman dherman at
Mon Jul 11 08:40:59 PDT 2011

No, a module determines its exports by itself, and no one can override that. Notice that you missed *two* export declarations, car.startCar *and* car.engine.start. If the engine module doesn't export start, then the outer car module cannot access it.


On Jul 10, 2011, at 11:19 PM, Kam Kasravi wrote:

> Yes, thanks, my mistake on the unexported startCar function declaration. My question is more about semantics, if the author of engine did not want to export start, the grammar allows anyone importing the engine module to override the original author's intent. 
> On Jul 10, 2011, at 8:11 PM, David Herman <dherman at> wrote:
>>> According to the module grammar, the following is valid:
>>> 691module car {
>>>   function startCar() {}
>>>   module engine {
>>>     function start() {}
>>>   }
>>>   export {start:startCar} from engine;
>>> }
>>> It seems like there would be issues with exporting module elements after the module has been defined.
>> I don't see any conflicts with the code you wrote, but it does contain a linking error, because the car module doesn't have access to the unexported start function. Maybe you intended:
>>     module car {
>>         export function startCar() { }
>>         module engine {
>>             export function start()  { }
>>         }
>>         export { start: startCar } from engine;
>>     }
>> In this case, you have a conflict, because the car module is attempting to create two different exports with the same name. This is an early error.
>>> Also, what is the behavior of aliasing over existing Identifiers? Would the compiler fail or would behavior 
>>> be the 'last' Identifier wins?
>> Early error.
>> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list