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.
Dave
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 <dher...@mozilla.com> 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
>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
