Iterator/Generator methods and Iterator Generics

Yuh-Ruey Chen maian330 at gmail.com
Mon Feb 5 23:13:02 PST 2007


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 idea
to put such iterator functions in the iterator namespace. |use namespace
iterator| would make the global iterator functions accessible without
qualifiers, but also make a public::get property unaccessible if
iterator::get was defined, 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
iterator|.

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.

Furthermore, it seems inconsistent that the static versions of map,
every, replace, etc. is placed on the built-in classes/constructors (at
least in JS1.6+), e.g. String.replace, while the iterator functions get
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?

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




More information about the Es4-discuss mailing list