modules proposal

Dmitry A. Soshnikov dmitry.soshnikov at
Sun May 16 11:19:55 PDT 2010

On 16.05.2010 22:11, Brendan Eich 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.

Ah, sorry, yes. * on import covers this need, so "all" is obsolete on 

>> 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.

Yep, I thought so too after that, so forget about this. The main purpose 
of a general export at the top of a file is a quick look on what are 
being exported (and convenience to write the only export statement) and 
"except" concept from this viewpoint is less informative. Moreover, 
again * on import eliminates this need.


More information about the es-discuss mailing list