modules, @std, selectively hiding/renaming imports

Sam Tobin-Hochstadt samth at
Fri Nov 25 05:10:45 PST 2011

On Fri, Nov 25, 2011 at 5:02 AM, Claus Reinke <claus.reinke at> wrote:
>>> From the early drafts of a standard library
>>> it appears we are headed for an import name clash between
>>> "Object.keys and "@iter.keys" - they cannot both be available as
>>> plain "keys".
>> Object is not a module, so there's no clash. Lots of methods named "keys"
>> these days.
>> Also the recent es-discuss thread on @iter suggests eliminating it in
>> favor of @reflect, which we want for Proxy helpers too.
> Perhaps I misunderstand the standard library idea: I thought
> the idea was to provide those identifiers in unqualified form,
> via an implicit import-* of "@std" (btw, is there a way to turn
> of the implicit import, making it explicit, for more selective
> import?).
> The "keys" from "Object" and from "@iter" can't both be in
> scope, yet both "Object"/"@reflect" and "@iter" seem to be
> scheduled for inclusion in "@std".

I think this is a misunderstanding because the "@object" module wasn't
mentioned at the top of that section of the wiki page, which I've now
corrected.  The current plan (which is very early, there has been
little discussion of this) has the `keys' function that produces an
iterator in "@std" and the `keys' function that is the same as
`Object.keys()' in the "@object" module.
sam th
samth at

More information about the es-discuss mailing list