I think Charles means examples like:
module Foo {
export var x = 1;
}
module Foo {
export var y = 2;
}
The answer is that this is a static error. Modules are not open and extensible.
You can't declare the same module name twice in the same scope. (This should be
made clearer in the subsection "Module binding and resolution," thanks for
asking about it.)
You can redeclare a new module with the same name at a different level of scope:
module Foo {
export var x = 1;
}
module Bar {
module Foo {
export var y = 2;
}
import Foo.x; // error: no such binding
}
Since modules are bound in the scope chain like everything else, the semantics
is just the same as all other lexical scope: the innermost binding of Foo wins.
Dave
On May 16, 2010, at 11:25 AM, Brendan Eich wrote:
> On May 16, 2010, at 11:15 AM, Charles Jolley wrote:
>
>> I am unclear from this proposal. What would happen if I declared the same
>> module twice? Would it reopen the module and add the extra declarations?
>
> The simple modules proposal makes it an error to export twice. This is a bit
> implicit in
>
> http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules#export_declarations
>
> That you get an error on duplicate export is a good point to make explicitly.
>
> Not sure if you meant Dmitry's "export *;" idea. That would export
> everything, but again if something was already exported, then there was
> already a const binding in the module's exports and you'd get an error.
>
> /be
>
>
>>
>> -Charles
>>
>>
>> On May 16, 2010, at 11:11 AM, Brendan Eich <bren...@mozilla.com> wrote:
>>
>>> On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
>>>
>>>> On 15.05.2010 19:22, Brendan Eich wrote:
>>>>> On May 15, 2010, at 7:53 AM, David Herman wrote:
>>>>>
>>>>>>> I wonder if you considered having an export list, rather than tagging
>>>>>>> the individual exports? I think that makes it easier to see/document
>>>>>>> the public API of a module. You could at the same time allow renaming
>>>>>>> on export.
>>>>>>
>>>>>> Yes, this is a good point. We chose inline-export for convenience, but I
>>>>>> don't see any reason not to allow both.
>>>>>
>>>>> +1 on an export form that takes a list of already-declared names.
>>>>>
>>>>
>>>> Besides, the variation with
>>>>
>>>> export all; // or export "all";
>>>>
>>>> can be considered. It can be useful for debug.
>>>
>>> Debugging is good.
>>>
>>> This is a minor point, but rather than all, we'd use * instead, to mirror
>>> import M.* or M.{*} or import * from M; whatever it ends up being.
>>>
>>>> Or, simply -- to omit export statement. Thus, if there will be no local
>>>> export statement for some function, it means that all functions/properties
>>>> are exported. Although, it breaks the first design where by default
>>>> methods are private for a module.
>>>
>>> Sorry, the idea of implicit everything-exported is a footgun. Just say no.
>>>
>>>
>>>> Excluding:
>>>>
>>>> export all except [intrinsic, builder]; // if we don't want to write 20 of
>>>> 22 methods to be exported
>>>
>>> This is overdesign. By far the most common case is explicit export of a
>>> select list of API functions and consts.
>>>
>>> /be
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
