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
