Re: Nov 17 meeting notes
On 11/17/2011 10:03 PM, Dominic Cooney wrote:
On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} | [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
Nit: This should be c = 3, because {2: 3} means ({2: x} | [1, 2])[2] is x,
right?
Correct. Sorry for the typo.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Nov 17 meeting notes
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} | [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
d = undefined.
r = empty.
Fixed property destructuring doesn't rely on length.
Vararg r destructuring uses length.
The semantics of length will match that of slice.
Allen: We may upgrade ToUint32 to ToInteger in various array semantics.
What should the semantics be if we allow fixed properties in the
middle of a destructuring?
[a, ... r, b] = [42]
What are the values of a, r, and b?
a = 42
r = []
b = undefined
Brendan:
[a, ... r, b] = [, 43] | [42]
What are the values of a, r, and b?
a = 42
r = []
b = 43 or undefined?
Array.from discussion: What happens if you subclass Array?
Subarray = Array | function() {...}
Subarray.from(arraylike)
DaveH:
Array.from = function(x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
Array.of = function(... x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
The above should skip holes.
MarkM: Now these functions are this-sensitive and will fail if
extracted and called indirectly.
DaveH: Replace 'new this()' with 'new (this || Array)()' above.
MarkM: Of all of the static methods in ES5, not one of them is
this-sensitive. The simple extraction of a static method fails,
thereby making static methods not be first-class. If Math.sin did
this, you couldn't map it over an array. With this, you can't map
Array.of over an array.
Doug: Concerned about the use of the word 'of'; confusion with for-of.
Wild debate over class hierarchies and class-side inheritance.
Deferred Array.from and Array.of due to concerns over this-sensitivity
until we figure out a proper class-side abstraction mechanism.
Array.from(a) is superfluous because it's expressed even simpler as
[... a]. DaveH withdrew it.
Array.pushAll:
Debate over whether this is a workaround for poor implementations of
using Array.push with spread or apply, or whether we should directly
have a second set of methods.
Brendan: Let's implement spread and optimize it first. Later we can
always add pushAll if it's needed. This isn't ... paving cowpaths;
this is a mountain goat that went too high.
DaveH: Very opposed to .{ .
Cut 'fine points of for-of' from this meeting due to time.
Batch assignment:
Is this ES6 or ES7? This is new, not discussed in May.
Can't discuss batch assignment without also discussing .{ .
Was .{ part of the May object literal proposal?
MarkM: Two kinds of .{ collisions to worry about. The object literal
just statically disallows them. .{ can have run-time property
collisions.
DaveH: Like the functionality but not the .{ syntax.
Example from .= page:
let element = document.querySelector('...');
element.{
textContent: 'Hello world'
}.{
style.{
color: 'red',
backgroundColor: 'pink'
}
}.{ // back on element
onclick: alert
};
Waldemar: Can you replace }.{'s with commas? Brendan: Not in general.
}.{'s do property redefinitions on property name conflicts, while
commas produce errors on conflicts.
Waldemar: Can you distribute the middle section above into the following?
}.{
style.{color: 'red'},
style.{backgroundColor: 'pink'}
}.{ // back on element
Answer: Maybe.
DaveH: Bind operator syntax strawman.
softBind strawman.
[A bunch of different discussions going on simultaneously, which I
couldn't track.]
Direct Proxies slide show.
Discussion about what hidden or implementation properties are passed
from the target through a direct proxy and how a proxy handler would
find out about all of them. The author of a proxy needs to keep up to
date about picking the correct target as we add hidden properties.
For example, to make an Array-like proxy object, a proxy should start
with an Array instance as the proxy target. Same with Date, etc.
Allen: There's no way to bootstrap -- can't define an Array-like proxy
if you don't have an Array target to start with.
Discussion about proxying the [[class]] name.
No more fundamental vs. derived traps. (Almost) all traps default to
the target object's behavior if not overridden. An exception is the
construct trap, which by default calls the call trap instead of
forwarding to the target object.
Allen: Should just pass through to the target.
Allen worried about other derived traps.
Waldemar: Always defaulting to the target will prevent us from ever
defining new non-leaf traps in the future, as that would break
existing proxies. For example, if we have a current trap API where
the proxy defines only the trap GET, and we later wish to evolve the
language to refactor the API to call the derived trap HAS followed by
GET, where an object's HAS is defined in terms of GET, then defaulting
to the target will break proxies because HAS will invoke the target's
GET instead of the proxy's GET.
MarkM: This is forwarding vs. delegation. The issue applies to many
traps, not just call. All
Re: Nov 17 meeting notes
On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat walde...@google.comwrote:
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} | [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
d = undefined.
r = empty.
Fixed property destructuring doesn't rely on length.
Vararg r destructuring uses length.
The semantics of length will match that of slice.
Allen: We may upgrade ToUint32 to ToInteger in various array semantics.
What should the semantics be if we allow fixed properties in the
middle of a destructuring?
[a, ... r, b] = [42]
What are the values of a, r, and b?
a = 42
r = []
b = undefined
Brendan:
[a, ... r, b] = [, 43] | [42]
What are the values of a, r, and b?
a = 42
r = []
b = 43 or undefined?
Array.from discussion: What happens if you subclass Array?
Subarray = Array | function() {...}
Subarray.from(arraylike)
DaveH:
Array.from = function(x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
Array.of = function(... x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
The above should skip holes.
MarkM: Now these functions are this-sensitive and will fail if
extracted and called indirectly.
DaveH: Replace 'new this()' with 'new (this || Array)()' above.
MarkM: Of all of the static methods in ES5, not one of them is
this-sensitive. The simple extraction of a static method fails,
thereby making static methods not be first-class. If Math.sin did
this, you couldn't map it over an array. With this, you can't map
Array.of over an array.
Doug: Concerned about the use of the word 'of'; confusion with for-of.
Wild debate over class hierarchies and class-side inheritance.
Deferred Array.from and Array.of due to concerns over this-sensitivity
until we figure out a proper class-side abstraction mechanism.
Array.from(a) is superfluous because it's expressed even simpler as
[... a]. DaveH withdrew it.
Perhaps Array.from() was either misunderstood or miscommunicated. I had
prepared a complete step-by-step production of the function's semantics and
documented them here:
https://gist.github.com/1074126
These steps support back compat to older JS (and DOM) implementations for
converting _any_ array looking object (arguments, DOM NodeLists,
DOMTokenList (classList), typed arrays... etc.) into a new instance of a
real array.
This is a real problem, in real JavaScript, in the real world. Considering
the positive response from actual developers in the JS community, I'd like
to ask that it be reconsidered.
Rick
Array.pushAll:
Debate over whether this is a workaround for poor implementations of
using Array.push with spread or apply, or whether we should directly
have a second set of methods.
Brendan: Let's implement spread and optimize it first. Later we can
always add pushAll if it's needed. This isn't ... paving cowpaths;
this is a mountain goat that went too high.
DaveH: Very opposed to .{ .
Cut 'fine points of for-of' from this meeting due to time.
Batch assignment:
Is this ES6 or ES7? This is new, not discussed in May.
Can't discuss batch assignment without also discussing .{ .
Was .{ part of the May object literal proposal?
MarkM: Two kinds of .{ collisions to worry about. The object literal
just statically disallows them. .{ can have run-time property
collisions.
DaveH: Like the functionality but not the .{ syntax.
Example from .= page:
let element = document.querySelector('...');
element.{
textContent: 'Hello world'
}.{
style.{
color: 'red',
backgroundColor: 'pink'
}
}.{ // back on element
onclick: alert
};
Waldemar: Can you replace }.{'s with commas? Brendan: Not in general.
}.{'s do property redefinitions on property name conflicts, while
commas produce errors on conflicts.
Waldemar: Can you distribute the middle section above into the following?
}.{
style.{color: 'red'},
style.{backgroundColor: 'pink'}
}.{ // back on element
Answer: Maybe.
DaveH: Bind operator syntax strawman.
softBind strawman.
[A bunch of different discussions going on simultaneously, which I
couldn't track.]
Direct Proxies slide show.
Discussion about what hidden or implementation properties are passed
from the target through a direct proxy and how a proxy handler would
find out about all of them. The author of a proxy needs to keep up to
date about picking the correct target as we add hidden properties.
For example, to make an Array-like proxy object, a proxy should start
with an Array instance as the proxy target. Same with Date, etc.
Allen: There's no way to bootstrap -- can't define an Array-like proxy
if you don't have an Array target to start with.
Discussion about proxying the [[class]] name.
No more fundamental vs. derived traps. (Almost) all traps default to
the target object's behavior if not overridden. An exception is the
Re: Nov 17 meeting notes
On Nov 17, 2011, at 4:40 PM, Waldemar Horwat wrote: Tom: Use a null target to indicate a permanently virtual object. Brendan: Proxy.DonJuan He refuses to commit. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Nov 17 meeting notes
On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote: On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat walde...@google.com wrote: Array.from(a) is superfluous because it's expressed even simpler as [... a]. DaveH withdrew it. Perhaps Array.from() was either misunderstood or miscommunicated. I had prepared a complete step-by-step production of the function's semantics and documented them here: It turns out that [...arrayLikeThingy] does exactly the same thing; it constructs a new Array from the contents of any array-like object. https://gist.github.com/1074126 These steps support back compat to older JS (and DOM) implementations for converting _any_ array looking object (arguments, DOM NodeLists, DOMTokenList (classList), typed arrays... etc.) into a new instance of a real array. This is a real problem, in real JavaScript, in the real world. Considering the positive response from actual developers in the JS community, I'd like to ask that it be reconsidered. The reason why we decided to table the statics was that we had some serious questions about inheritance of statics and how they should behave, which is part of the ongoing discussions about classes. Given that spread (the ... syntax) gives you exactly the behavior you want, and it's actually very clear and even more concise than Array.from, it didn't seem worth taking more time discussing it now. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Nov 17 meeting notes
On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat walde...@google.comwrote:
Array destructuring and length:
let [a, b, c, d, ... r] = {2: 3} | [1, 2]
Obvious: a is 1; b is 2.
What are c, d, and r?
c = 2.
Nit: This should be c = 3, because {2: 3} means ({2: x} | [1, 2])[2] is x,
right?
d = undefined.
r = empty.
Fixed property destructuring doesn't rely on length.
Vararg r destructuring uses length.
The semantics of length will match that of slice.
Allen: We may upgrade ToUint32 to ToInteger in various array semantics.
What should the semantics be if we allow fixed properties in the
middle of a destructuring?
[a, ... r, b] = [42]
What are the values of a, r, and b?
a = 42
r = []
b = undefined
Brendan:
[a, ... r, b] = [, 43] | [42]
What are the values of a, r, and b?
a = 42
r = []
b = 43 or undefined?
Array.from discussion: What happens if you subclass Array?
Subarray = Array | function() {...}
Subarray.from(arraylike)
DaveH:
Array.from = function(x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
Array.of = function(... x) {
var result = new this();
for (var i = 0, n = x.length; i n; i++)
result[x] = x[i];
return result;
}
The above should skip holes.
MarkM: Now these functions are this-sensitive and will fail if
extracted and called indirectly.
DaveH: Replace 'new this()' with 'new (this || Array)()' above.
MarkM: Of all of the static methods in ES5, not one of them is
this-sensitive. The simple extraction of a static method fails,
thereby making static methods not be first-class. If Math.sin did
this, you couldn't map it over an array. With this, you can't map
Array.of over an array.
Doug: Concerned about the use of the word 'of'; confusion with for-of.
Wild debate over class hierarchies and class-side inheritance.
Deferred Array.from and Array.of due to concerns over this-sensitivity
until we figure out a proper class-side abstraction mechanism.
Array.from(a) is superfluous because it's expressed even simpler as
[... a]. DaveH withdrew it.
Array.pushAll:
Debate over whether this is a workaround for poor implementations of
using Array.push with spread or apply, or whether we should directly
have a second set of methods.
Brendan: Let's implement spread and optimize it first. Later we can
always add pushAll if it's needed. This isn't ... paving cowpaths;
this is a mountain goat that went too high.
DaveH: Very opposed to .{ .
Cut 'fine points of for-of' from this meeting due to time.
Batch assignment:
Is this ES6 or ES7? This is new, not discussed in May.
Can't discuss batch assignment without also discussing .{ .
Was .{ part of the May object literal proposal?
MarkM: Two kinds of .{ collisions to worry about. The object literal
just statically disallows them. .{ can have run-time property
collisions.
DaveH: Like the functionality but not the .{ syntax.
Example from .= page:
let element = document.querySelector('...');
element.{
textContent: 'Hello world'
}.{
style.{
color: 'red',
backgroundColor: 'pink'
}
}.{ // back on element
onclick: alert
};
Waldemar: Can you replace }.{'s with commas? Brendan: Not in general.
}.{'s do property redefinitions on property name conflicts, while
commas produce errors on conflicts.
Waldemar: Can you distribute the middle section above into the following?
}.{
style.{color: 'red'},
style.{backgroundColor: 'pink'}
}.{ // back on element
Answer: Maybe.
DaveH: Bind operator syntax strawman.
softBind strawman.
[A bunch of different discussions going on simultaneously, which I
couldn't track.]
Direct Proxies slide show.
Discussion about what hidden or implementation properties are passed
from the target through a direct proxy and how a proxy handler would
find out about all of them. The author of a proxy needs to keep up to
date about picking the correct target as we add hidden properties.
For example, to make an Array-like proxy object, a proxy should start
with an Array instance as the proxy target. Same with Date, etc.
Allen: There's no way to bootstrap -- can't define an Array-like proxy
if you don't have an Array target to start with.
Discussion about proxying the [[class]] name.
No more fundamental vs. derived traps. (Almost) all traps default to
the target object's behavior if not overridden. An exception is the
construct trap, which by default calls the call trap instead of
forwarding to the target object.
Allen: Should just pass through to the target.
Allen worried about other derived traps.
Waldemar: Always defaulting to the target will prevent us from ever
defining new non-leaf traps in the future, as that would break
existing proxies. For example, if we have a current trap API where
the proxy defines only the trap GET, and we later wish to evolve the
language to refactor the API to call the derived trap HAS followed by
GET, where
Nov 17 meeting notes
Here are my meeting notes for today. Waldemar WebIDL: Can abstract interfaces have static members? Don't see why not -- they'd just be spec sugar for adding the same static member to concrete classes that derive from those abstract interfaces. As usual, it would be a spec error to have a collision. Debate over combination of overloaded methods from different base abstract interfaces. Issues come up with combining overloads of abstract types -- per yesterday, the structural union of two abstract interfaces A1 and A2 can contain instances that are in neither A1 nor A2. General feeling is to avoid the issues if feasible. Property enumeration order: Decided that this is a TC39/ECMAScript issue, not a WebIDL issue. Dealing with argument count mismatches: Ignoring additional arguments is useful for upwards compatibility (example: adding an extra dirty region argument to draw methods that would be ignored by older browsers that would just redraw the whole canvas). Overloading is a mismatch with future-proofing argument count mismatches. Proposal: treat each function call as having infinitely many trailing undefined arguments, and overload only on types, not argument count. Brendan on special operations: don't want to see any more of these darken our door. Trouble is that these kinds of catch-alls allow most names but not all names, leading to brittle or exploitable code. It's better to provide get and set methods. However, Stringifiers are ok. Error objects have their string properties (name and message) defined on their prototypes in ES3. IDL errors can create instances with instance properties for name and message rather than delegating to a prototype, and everything ought to work. Browsers like to add other properties to Error objects they create. Not clear how to link into that functionality. Throw this back to TC39's core language discussions. Returned sequence types are returned as arrays. That means that they must be copies each time they're returned. Should they be frozen? Not much enthusiasm for that What about passing arrays into IDL? The IDL can just access whatever it wants because it has control until it returns. Except that it doesn't if there are getters, setters, or proxies in the data structure passed to IDL -- the order of accesses is discoverable, and the data structure can mutate itself as it's being read. The proposal of having IDL read data structure as if copied is not practical. Some methods might only want to access one element of an array and don't want to copy the whole thing. We won't require users to freeze arrays before passing them into IDL. That would be too cumbersome. We won't require IDL to freeze arrays before passing them to users. Every array will be fresh. Discussion about indexGetter and indexSetter. Separate path for looking up numerical indices? John, Brendan: Want to avoid high management overhead for cooperating with W3C. A lot of liaisoning formality or large meeting would be undesirable. Discussion about desirability of writing a style guide or joining TAG. Style guide may be ineffectual -- it's better to just have somone who understands style review proposals -- while TAG has no teeth to enforce its mission, so it's practically been ignored. --- Next meeting on Jan 18-20 at Yahoo. Ballot resolution meeting at 3pm on Jan 19. We'll send the final ISO draft to ISO tomorrow (Thursday) and also place the draft on the ECMA website. Allen: Need to re-designate the document as a draft if we let it out now. Consensus on removing the test results altogether from the test262.ecmascript.org web site. Having results there would provide too many incentives for trying to game the system rather than build a good test suite. Debate on whether do commit-before-review or review-before-commit on the test suite. Would be good to get rid of the powershell platform dependency when submitting tests. Discussion about whether we can get rid of -0. Some are in favor but no, we can't. We also can't make -0 !== +0. Either would be a large breaking change. Some desire to make the identity operation syntactically as attractive as ===. Could we make the identity operation into an infix operator named eq? Waldemar: Syntactically, we could, and we wouldn't even need to make eq into a reserved word. The production would have to be: expr1 [no line break here] eq expr2 The reason the [no line break here] has to be in the first gap instead of the second one is to maintain compatibility with the existing code that counts on semicolon insertion: a = x eq = y which would continue to parse as: a = x; eq = y; Agreed to move this into the proposal stage. const function joining: Vigorous debate. Some don't like specifying the optimization algorithm. What is its asymptotic complexity? Oliver would object if it's greater than n*log(n) but might object anyway. Waldemar: Opposed to mandating making dead code change semantics of live code, as
