Iterator/Generator methods and Iterator Generics
brendan at mozilla.org
Tue Feb 6 10:45:08 PST 2007
On Feb 5, 2007, at 11:13 PM, Yuh-Ruey Chen wrote:
> Brendan Eich wrote:
>> But I do not believe they should be fixed or prototype methods of
>> nominal types (classes). Rather, they should simply be generic
>> functions in the iterator namespace, (e.g. iterator::zip or use
>> namespace iterator; ... zip(...)).
>> With Array and String, ES1-3 stipulated generic prototype methods,
>> making for awkwardness when applying to other kinds of objects. For
>> ES4, as in JS1.6+, we are reflecting these as static generic methods
>> on their classes, simply using the classes as namespaces. With the
>> iterator namespace, we can do better and simply write functions.
>> That's what zip, etc., are -- they are not methods
> I was thinking about this some more. I'm not sure it's such a good
> to put such iterator functions in the iterator namespace. |use
> iterator| would make the global iterator functions accessible without
> qualifiers, but also make a public::get property unaccessible if
> iterator::get was defined
No, you could always say what you mean: obj.public::get.
> , so if I do obj.get, I can't tell whether I'm
> getting public::get or iterator::get unless I manually test
> obj.iterator::get, which kinda defeats the purpose of |use namespace
Namespaces are like that. If you don't want implicit qualification,
don't use namespace foo.
> It would be nice if there was a convenient way to bind each iterator
> function x to the public namespace in global scope, without having to
> use |use namespace iterator| (to avoid the aforementioned problem) or
> manually binding each such function x.
This is an argument for putting itertools-like functions in a package
or namespace other than iterator. Which I see you propose below :-).
> Furthermore, it seems inconsistent that the static versions of map,
> every, replace, etc. is placed on the built-in classes/constructors
> least in JS1.6+), e.g. String.replace, while the iterator functions
> placed in another namespace. The iterator functions could be static
> methods of the Iterator class to be consistent. Or would all these
> static functions be moved to other namespaces?
Having an Iterator class is problematic. I'm revising the wiki now
and I'm not done yet, but one goal is to avoid telegraphing that
there is some nominal-type-system protocol behind iteration, and to
participate you have to subclass Iterator -- or any such thing.
> Since we have packages, why not place static functions in them instead
> of namespaces or classes? itertools.ifilter instead of
> iterator::ifilter. Then we could use the import statement to bind
> itertools.ifilter to global.ifilter.
This is the right way to go, especially if the Python itertools are
ported under their names (but they want to drag in slice, map, and
other Python generic functions). Still the right way to go, modulo
that parenthetical concern.
> It would be nice if iterator or
> Iterator could be used as the package name, but that would result in a
> name conflict with the iterator namespace, wouldn't it?
iterator is the namespace name, a global constant binding. It seems
from our spidering not to be taken (prototype.js uses iterator for
local var names, no problem). Package names are a matter not
addressed by ES4, but the obvious reversed FQDN prefixing seems
likely. The Flex SDK does something like this, but IIRC the first
component is "mx" (not com.macromedia or com.adobe ;-).
In any event, package names for standard library packages need to be
sorted out for ES4, IMHO, but we haven't done it yet.
More information about the Es4-discuss