RE: ES4 draft: enumerability
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jason Orendorff > Sent: 24. april 2008 09:53 > To: Brendan Eich; es4-discuss > Subject: Re: ES4 draft: enumerability > > The iterator proposal: > http://wiki.ecmascript.org/doku.php?id=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. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: enumerability
The iterator proposal: http://wiki.ecmascript.org/doku.php?id=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). -j ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: enumerability
On Apr 22, 2008, at 2:06 PM, Jason Orendorff wrote: > On 2008/4/10, Lars Hansen <[EMAIL PROTECTED]> 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 http://wiki.ecmascript.org/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. 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. 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. must mean IterableType., 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.. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: enumerability
On 2008/4/10, Lars Hansen <[EMAIL PROTECTED]> 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. 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.) = false) : Iterable. Either way, DEFAULT_GET is easily defined in terms of that. -j ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: 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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
ES4 draft: enumerability
Here's the first draft explaining how enumeration works in ES4.
--lars
Title: Enumeration
Enumerability
NAME: "Enumerability"
FILE: spec/language/enumerability.html
CATEGORY: Object model
SOURCES:?
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 1 - 2008-04-10
REVIEWED AGAINST ES3: NO
REVIEWED AGAINST ERRATA:NO
REVIEWED AGAINST BASE DOC: NO
REVIEWED AGAINST PROPOSALS: NO
REVIEWED AGAINST CODE: NO
REVIEWED AGAINST TICKETS: NO
IMPLEMENTATION STATUS: ?
TEST CASE STATUS: ?
OPEN ISSUES
* The rationale for the decision not to enumerate fixture properties
is a bit feeble.
REFERENCES
[1] proposals:iterators_and_generators
[2] http://www.ecmascript.org/es4/spec/Object.html
[3] proposals:bug_fixes [FOR.IN.LOOP.CREATION.ORDER]
[4] ES3 spec 12.6.4
[5] proposals:bug_fixes [ITERATE.NULL.AND.UNDEFINED]
Synopsis
The purpose of the present spec is to define what it means for a
property of an object to be "enumerable", that is, what it means for
the property to be discovered when the properties of an object are
enumerated by for-in and for-each-in loops [4].
This spec also describes in high level terms the facilities that
are available to user programs to implement variations on enumeration.
Enumeration and itemization in ES4
According to [1], enumeration and itemization in ES4 is specified
in terms of the new iterator protocols using a system-defined helper
class called Enumerator. A section below contains a brief
description of how the translation is performed. The central point is
that enumeration is implemented by an Enumerator instance.
The constructor of
Enumerator optionally takes some namespace values:
iterator class Enumerator. {
public function Enumerator(obj, f, deep, ...namespaces) {
...
}
public function next(): T {
...
}
}
An Enumerator created on an object obj will produce (from
its next method) a succession of the enumerable properties of
obj: those dynamic properties of obj whose "enumerable"
attribute [2] is set, filtered by the contents of namespaces. If
deep is true, then the objects in the prototype chain of obj
are included in the enumeration. Enumeration is always performed
starting at obj; properties are produced in the order they were
inserted into obj [3]; when the properties in obj are
exhausted the process is repeated on the immediate prototype of
obj, if any.
There is a distinct namespace in ES4 known as the "compatibility
namespace" or "no namespace". In code, this namespace is denoted by
the keyword public.
When an Enumerator is created with an empty set of namespaces,
it filters the enumerable attributes by the compatibility namespace,
and all property names produced are string values -- the property
name without the namespace, because the namespace is always the
compatibility namespace.
When an Enumerator is created with a nonempty set of
namespaces, it filters the enumerable attributes by those namespaces
only, and all property names produced are Name values: namespace
and name pairs.
(Punchline.) Normal enumeration and itemization by the
for-in and for-each-in loops result in the
creation of Enumerator instances with an empty sets of namespaces
and deep set to true. Ergo, normal enumeration behaves as in
ES3.
Programs that needs to enumerate properties in specific
namespaces, or that only need to perform shallow enumeration, can
create custom Enumerator classes. It is possible that ES4 ought
to provide utility functions to make this simple, but experimentation
will show.
Rationale and discussion
The rephrasing of enumeration in terms of iteration allows the
for-in and for-each-in statements to be used for
iteration, which is exceptionally handy.
Regarding namespace filtering and enumeration by default of only
public properties: Namespaces are used by user programs for privacy
and integrity. For example, the private attribute on properties
and methods of a class is just the name of a system-generated
namespace. It would be a breach of privacy for arbitrary code to be
able to enumerate arbitrary properties on an object, since the private
property names would be revealed in the form of Name objects, from
which the private namespace could be exposed. Yet it is useful for
code to enumerate properties in namespaces controlled by that code.
So the compromise -- which is also right for compatibility with ES3 --
is that only public properties are enumerated by default; all
system-provided namespaces can be obtained by naming them (a class
method can evaluate the _expression_ private to obtain the object
representing its private namespace); and custom Enumerator
instances can be constructed to enumerate names in
