ES4 draft: enumerability
My comments on this chapter:
I understand and agree with the simple form of iteration though an object using the empty set of namespaces.
On the other hand, I don't see why extending this beyond that functionality is useful. It makes things larger and more complicated and, given that namespaced fixtures aren't enumerated anyway, isn't useful for anything I'd want to use it for like exploring the environment or introspecting data held in records some of whose properties are const.
Waldemar
On 2008/4/10, Lars Hansen <lhansen at adobe.com> wrote:
Here's the first draft explaining how enumeration works in ES4.
-
It's unclear which parts of this, if any, are intended to be normative.
-
Are the terms "enumeration", "iteration", and "itemization" defined somewhere? Even if they are, I can't stop reading the first two as synonyms, so I'd welcome a change in terminology. Perhaps "for-in iteration" for "enumeration", and "for-each-in iteration" for "itemization"?
-
The treatment of for-each-in (the last sentence) is a bit vague. The only difference is how the iterator "IT" is obtained, right? But that needs to be specified.
Renaming "GET" and "DEFAULT_GET" to something like "FOR_ITERATOR" and "DEFAULT_FOR_ITERATOR" would leave room for "FOR_EACH_ITERATOR" and "DEFAULT_FOR_EACH_ITERATOR".
-
The iterator proposal specifies additional special behavior when the iterator "IT" is a generator-iterator. Intentionally omitted here?
-
Is a more general introspection facility planned? If so, I hope DEFAULT_GET can be defined in terms of that and the Enumerator class can be dropped.
-
The design of Enumerator doesn't make sense to me, especially that it's a parameterized class. What's the design goal here?
To expose "get obj's public, enumerable properties, just like ES3 for-in", a static method suffices:
Object.getEnumerableProperties(obj: Object!): Iterable.<string>
If the goal is to expose a general API for getting various slices of an object's set of property names, a static method still suffices:
Object.properties( obj: Object!, deep: boolean = true, withDontEnum: boolean = false, namespaces: (boolean|Iterable.<Namespace>) = false) : Iterable.<Name>
Either way, DEFAULT_GET is easily defined in terms of that.
On Apr 22, 2008, at 2:06 PM, Jason Orendorff wrote:
On 2008/4/10, Lars Hansen <lhansen at adobe.com> wrote:
Here's the first draft explaining how enumeration works in ES4.
It's unclear which parts of this, if any, are intended to be normative.
Are the terms "enumeration", "iteration", and "itemization" defined somewhere?
They are defined in doku.php? id=proposals:iterators_and_generators, at least.
Even if they are, I can't stop reading the first two as synonyms, so I'd welcome a change in terminology. Perhaps "for-in iteration" for "enumeration", and "for-each-in iteration" for "itemization"?
Those are mouthfuls. After some up-front definition, would not the
shorter terms of art start to sink into your subconscious? They did
in mine, but probably that's because enumeration is such a beast in
JS, and iteration a la Python so much less full of baggage (unless
the iterator author wants baggage). Also, Pythonic keys/values/items
naming is short and sweet.
Renaming "GET" and "DEFAULT_GET" to something like "FOR_ITERATOR" and "DEFAULT_FOR_ITERATOR" would leave room for "FOR_EACH_ITERATOR" and "DEFAULT_FOR_EACH_ITERATOR".
See DEFAULT_GET_VALUES and DEFAULT_GET_ITEMS in the proposal.
- The iterator proposal specifies additional special behavior when the iterator "IT" is a generator-iterator. Intentionally omitted here?
Do you mean it.close() automation? See also http:// bugs.ecmascript.org/ticket/47.
- Is a more general introspection facility planned? If so, I hope DEFAULT_GET can be defined in terms of that and the Enumerator class can be dropped.
Something has to specify enumeration, and we prefer self-hosting to
prose for library code. Why is Enumerator objectionable?
- The design of Enumerator doesn't make sense to me, especially that it's a parameterized class. What's the design goal here?
This is going to sound too technical and it immediately raises
another question, but it's not arbitrary, and I'll answer the further
question too:
To satisfy iterator::IteratorType.<T> while implementing deep and
shallow enumeration (a la ES1-3 for (i in o) loop) and itemization
(E4X's for each (v in o) loop).
Ok (you ask), why satisfy that generic structural type? Because
that's the return type for the one iteration protocol hook,
iterator::get, which ES4 checks to allow custom and superior
iteration under the common, desired, and well-known for-in syntax.
Alternatives adding different syntax lose for not being Pythonic
(ignore mandatory parens) and adding more special forms. Really,
enumeration is a one-size-does-not-fit-all default that we want to
keep for compatibility, but allow objects and classes to customize.
Just like in Python (if you squint with those beer^H^H^H^HJS-colored
glasses ;-).
To expose "get obj's public, enumerable properties, just like ES3 for-in", a static method suffices:
Object.getEnumerableProperties(obj: Object!): Iterable.<string>
Not quite. See the discussion at the top of the proposal.
-
Something has to filter property identifiers deleted after
enumeration or itemization starts but before those ids are visited in
the snapshot. -
Something has to implement shadowing for deep properties (those
found in a prototype object but having the same identifier as a
property in the directly referenced object or a nearer object along
its prototype chain).
These two, plus conversion of indexes to string type, are the hairy
aspects of enumeration that we wish to implement under a uniform
iteration protocol.
Also, Iterable.<string> must mean IterableType.<string>, as there's
no type named Iterable in the proposal at least (did it get renamed?
Checking... no, still IterableType).
If the goal is to expose a general API for getting various slices of an object's set of property names,
... while also matching IteratorType.
a static method still suffices:
A static method does not suffice for the "matching IteratorType"
requirement.
IOW, the for-in construct (whether loop statement or comprehension,
with or without 'each') is layered on a general iteration protocol
hook a la Python's iter. But that hook is a typed function, and
the return value is of type IteratorType.<T>.
The iterator proposal: proposals:iterators_and_generators is out of date or seems contradictory in several places:
-
Do implementations have to provide the primitives in the "magic" namespace?
In one place, the proposal says, "The magic::getEnumerableIds primitive is a specification device only.", but then it says things like, "the new magic::getEnumerableIds primitive" and "As specified above under Enumeration, magic::getPropertyIds returns an array..." which make it sound like a standard feature, visible to ES4 programs.
-
I think this sentence is obsolete: "To customize for ([k, v] in o) loops and comprehensions, set iterator::getItems."
-
Under "Comprehensions", the new "let" syntax isn't there yet.
-
The implementation of DEFAULT_GET visits properties outside the public namespace; I think that's out of date. (It seems unuseful anyway, as in that case DEFAULT_GET discards the namespace and produces the identifier.)
-
The proposal claims Object implements ItemizableType, but I think that was scrapped as well.
-
The proposal says for-in loops specially close() "newborn" generator-iterators. I think this has changed.
I have more substantive comments on this proposal (to follow).
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Jason Orendorff Sent: 24. april 2008 09:53 To: Brendan Eich; es4-discuss Subject: Re: ES4 draft: enumerability
The iterator proposal: proposals:iterators_and
_generators
is out of date or seems contradictory in several places:
- Do implementations have to provide the primitives in the "magic" namespace?
No. More than that, they may not provide those primitives except as a vendor extension (which presumably will be allowed by the spec), but since many of them are abstraction-breaking it will not be wise to do so.
Here's the first draft explaining how enumeration works in ES4.