modules proposal

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
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 
export.

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

Dmitry.


More information about the es-discuss mailing list