On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat <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?
> 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 non-leaf traps should be resolved in the
> same way.
> Allen: Get rid of non-leaf traps (i.e. make them nonoverridable,
> allowing proxies to override only the leaf traps into which the
> non-leaf traps decompose).
> MarkM: Why?
> Waldemar: Are there any derived traps that have additional
> intelligence not expressible via the leaf traps which they call?
> Allen: Future-proofing is not important because we're unlikely to
> change the proxy API in the future.
> Waldemar: Counterexamples: Classes (if they're not just sugar),
> guards, value proxies, ...
> Sam, MarkM: The language provides a prototype handler with reasonable
> defaults for derived traps. Proxy handlers derive their handlers from
> that prototype. When the language evolves to create new traps, the
> language's prototype handler evolves in lockstep to keep existing
> proxies working.
> Discussion about double-lifting (making the proxy handler also be a
> proxy so it can abstract over the proxy trap API) and future-proofing
> membranes.
>
> Make target always be the first handler parameter instead of always
> being the last? That would make it match the Reflect API.
> What does receiver do in Reflect.get/set/call(target, receiver, ...)?
> Make target first and receiver last in the handler API. The Reflect
> API can drop the extraneous receiver parameter.
> MarkM: That doesn't make sense for Reflect.call. The order should be
> Reflect.call(target, receiver, args), not Reflect.call(target, args,
> receiver). Note that args is an array, not a spread list of
> arguments.
> Discussion about what Reflect.call should be called. The name
> "invoke" was invoked. "apply" might also apply here.
>
> Object.preventExtensions is a leaf trap and calls
> handler.protect('preventExtensions').
> Object.seal and Object.freeze: Should these call
> handler.protect('seal') and handler.protect('freeze')? Replace them
> with separate handler traps? Replace them with calls to a large
> number of separate traps that individually seal or freeze properties?
>
> MarkM: Why not define call behavior as target function behavior
> instead of having a call trap?
> Waldemar: That would break double lifting.
>
> Nonconfigurability invariants:
>
> Waldemar: get/set can still get and set own properties even on frozen
> objects with fully frozen prototype chains.
> Sam, MarkM: True. Unfortunately it's too hard to enforce this invariant.
>
> Tom: Use a null target to indicate a permanently "virtual" object.
> Brendan: Proxy.DonJuan
>
> Tom: Replace synchronization actions with throws if the
> synchronization actions would make any modifications to the target
> object.
>
> Discussion of __proto__.
> Brendan: It's a real use case in object literals.
>
> Proxy.stopTrapping:
> Can approximate this by deleting all handler bindings from the handler.
> MarkM: Swap arrow by making the proxy be the target and target be a proxy?
> Consensus: Dropped stopTrapping
>
> Refactoring prototype climbing in the spec.
> Refactoring:
> Brendan: Don't get rid of Object.getPropertyDescriptor and
> Object.getPropertyNames even if they aren't traps.
>
> Bikeshedding Proxy.for and Proxy.create names.
> Why isn't Proxy a module?
> if it's a module, can't use Proxy.for unqualified because it's a keyword.
>
> Tom: Direct proxy refactoring takes care of the set/put/canPut chaining
> problem.
>
> Should we have a defaultValue trap?
> Brendan: Leave it out for now. Revisit when we do value proxies.
>
> Attach:
> If target is a proxy, call a new trap.
> Tie ability to attach to object extensibility.
> Waldemar: Won't work for host objects that need to be both secure and
> extensible.
> MarkM: This is especially evil in capturing function arguments. If
> Alice gives Bob and Cathy a plain ES5 function, Cathy can't peek at
> the arguments Bob passes to the function when he calls it. With
> Attach, Cathy can intercept Bob's calls to Alice's function and,
> worse, make the function do something different for Bob.
> Discussion about whether this should be done. A number of us want
> value observers and feel that proxies are less useful without them.
> DaveH: There are many things that are wanted that didn't make the ES.next
> cut.
>
> Consensus: Direct proxies (other than startTrapping/attach) accepted
> for ES.next to replace older proxies proposals and strawmen.
>
>
> 2012 meetings:
> Jan 18-19 at Yahoo
> Mar 28-29 Google
> May 23-24 Northeastern University, Boston
> Jul 25-26 Microsoft Redmond
> Sep 24-25 Mozilla
> Nov 28-29 Apple
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
