Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
I think the refutable-by-default patterns need a ? modifier only for a
leaf identifier in a pattern, not for non-terminal identiifers. For
example:
let {p: {q: r}} = deep_o;
wants to get o.p.q and bind it to r.
With the current irrefutable design, if deep_o = {} or another object
lacking a {q:...} sub-object named p, then this example will fail with a
TypeError even though a shallow example fails-soft (or fails slowly,
really: fails later) by pulling undefined out as the value of p and
binding it to the local (as in the first example in this post).
With a refutable-by-default design, however, it seems to me nonsensical
to support ? on p as well as q in this example:
let {p?: {q?: r}} = deep_o;
because if deep_o has no property p, what should happen? No binding r at
all? Or a let binding named r with value undefined? What if there's no ?
after q in this case -- should that matter?\
We already rejected CoffeeScript's existential operator because of its
lack of compositionality. See
https://mail.mozilla.org/pipermail/es-discuss/2012-September/025232.html
(the section starting ARB: This is non-compositional). I think the
same objection applies to allowing p? in the deep_o case.
I advised adding Null Pattern Object into language in the aforementioned
thread; and use foo? as `foo == null ? NullPatternObject : foo`.
So you can do `r = o?.p.q`; and it does not fail.
With such construct you could do
let {p: {q: r}} = deep_o?;
Comments welcome. I'll put this on this month's TC39 meeting agenda.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
I advised adding Null Pattern Object into language in the
aforementioned thread; and use foo? as `foo == null ?
NullPatternObject : foo`.
So you can do `r = o?.p.q`; and it does not fail.
Separate topic, and we considered it as an alternative to CoffeeScript's
non-compositional rewrite-based semantics at the September TC39 meeting,
but did not proceed. Thanks for the reminder, I will update
http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator.
With such construct you could do
let {p: {q: r}} = deep_o?;
This does not address the problem for destructuring. It's true a Nil
object (as Brandon Benvie prototyped:
https://github.com/Benvie/nil/blob/master/nil.js) can be deeply
destructured. But there is no refutable match future. We need an
exception on missing property, not a magic get/set-sink object.
The suffix-? syntax in expressions is problematic in combination with
missing semicolons. You get another case where programmers expect ASI
but there's no error to correct:
x = y?
z:w
where z is label and w is a statement that can syntactically (if not
sensibly) be labeled.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
I advised adding Null Pattern Object into language in the
aforementioned thread; and use foo? as `foo == null ?
NullPatternObject : foo`.
With such construct you could do
let {p: {q: r}} = deep_o?;
This does not address the problem for destructuring. It's true a Nil
object (as Brandon Benvie prototyped:
https://github.com/Benvie/nil/blob/master/nil.js) can be deeply
destructured.
That is what I meant.
But there is no refutable match future. We need an
I don't understand. :-/
exception on missing property, not a magic get/set-sink object.
Without ?, it can throw. With it, it does not because of how Nil works.
The suffix-? syntax in expressions is problematic in combination with
missing semicolons. You get another case where programmers expect ASI
but there's no error to correct:
x = y?
z:w
where z is label and w is a statement that can syntactically (if not
sensibly) be labeled.
... or whatever other syntax. It's about Null Pattern idea, not the
actual syntax.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
This does not address the problem for destructuring. It's true a Nil
object (as Brandon Benvie prototyped:
https://github.com/Benvie/nil/blob/master/nil.js) can be deeply
destructured.
That is what I meant.
Thought so ;-).
But there is no refutable match future. We need an
I don't understand. :-/
We want a way to match with patterns like so:
match (expr) {
case {must, may?} = ...
case {always} = ...
}
In other words, the ? must go in the LHS pattern language, not on the
RHS of a destructuring binding or assignment expression.
missing semicolons. You get another case where programmers expect ASI
but there's no error to correct:
x = y?
z:w
where z is label and w is a statement that can syntactically (if not
sensibly) be labeled.
... or whatever other syntax. It's about Null Pattern idea, not the
actual syntax.
Ok, but we need a concrete syntax that works if we want anything like
CoffeeScript's suffix-? operator. And I agree suffix-? is attractive.
But it seems like a non-starter based on the use of ? in ?: and : in
labeled statements. Perhaps there's a tweak that saves this concrete
syntax, though?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
But there is no refutable match future. We need an
I don't understand. :-/
We want a way to match with patterns like so:
match (expr) {
case {must, may?} = ...
case {always} = ...
}
In other words, the ? must go in the LHS pattern language, not on the
RHS of a destructuring binding or assignment expression.
I see. You need o.?p more than o?.p, so you can write (informally)
o.{foo, ?bar}.
What about the above, then? So you can write foo.?bar to mean `foo.bar
== null ? Nil : foo.bar`. Then it naturally follows that you can as well
do `let {must:must, ?may:may} = o` which can be shortened. And it can go
deeper, since it is Nil.
(but again, syntax may conflict with existing use)
Ok, but we need a concrete syntax that works if we want anything like
CoffeeScript's suffix-? operator. And I agree suffix-? is attractive.
But it seems like a non-starter based on the use of ? in ?: and : in
labeled statements. Perhaps there's a tweak that saves this concrete
syntax, though?
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
Then it naturally follows that you can as well do `let {must:must,
?may:may} = o` which can be shortened.
Yes, that was the syntax we talked about earlier this year, but I think
CoffeeScript and TypeScript make a case for suffix-?.
And it can go deeper, since it is Nil.
What is Nil? There is no requirement with ? in the pattern language (on
the LHS) for the RHS to be of any particular type.
I like Nil, and it may help rescue ?. the existential operator strawman.
But that is in the expression language, not in the pattern language.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
Then it naturally follows that you can as well do `let {must:must,
?may:may} = o` which can be shortened.
Yes, that was the syntax we talked about earlier this year, but I think
CoffeeScript and TypeScript make a case for suffix-?.
And it can go deeper, since it is Nil.
What is Nil? There is no requirement with ? in the pattern language (on
the LHS) for the RHS to be of any particular type.
I like Nil, and it may help rescue ?. the existential operator strawman.
But that is in the expression language, not in the pattern language.
I like not to make things unnecessarily disjoint. Here I see the
possibility of having pattern language (in future patterns as well as in
present destructuring) having same semantics as the expression language
_with_throwing_on_nonexistent_property_ (that is what you asked in this
thread, unless I did not understand).
That is, these are identical, except the syntax:
r = o.p.q {p: {q: r}} = o
r = o.?p.q {?p: {q: r}} = o
P=o.p; Q=o.?q {p: P, ?q: Q} = o
With it can go deeper, since it is Nil I meant the second line, where
(o.?p) produces Nil, so o.?p.q being Nil.q produces Nil as well, without
throw.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Return values of mutating MOP operations (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))
On Dec 31, 2012, at 4:27 AM, Tom Van Cutsem wrote:
2012/12/31 Allen Wirfs-Brock al...@wirfs-brock.com
responses for chapter 8, except for 8.5 which will get its own message.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
Table 8:
* [[PreventExtensions]] internal method: should return a Boolean success
value
Why? no caller of [[PreventExtension]] currently uses such a result. In
general, we did try to make more of the internal methods return true/false
success indicators rather than deeply burying the decision of whether or not
an exception should be generated on failure. Do you have something in mind
where a caller of [[PreventExtension]] within the spec. (or a caller of
Reflect.preventExtensions) needs a true/false success code? Or maybe we
should just do it for consistency sake.
Three reasons:
1) As you say, consistency with [[DefineOwnProperty]], [[Delete]] and [[Set]]
(maybe also [[SetInheritance]]). Every operation that mutates an object
returns a success code indicating whether or not the intended change took
place.
2) Before proxies and symbols, [[PreventExtensions]] could never fail. With
the advent of new exotics, this operation may be rejected. Proxies and
symbols need a way to signal this. Essentially Object.preventExtensions
should throw a TypeError when [[PreventExtensions]] return false.
Object.preventExtensions should never fail silently on a proxy that rejects
the operation.
Symbols don't need to fail on [[PreventExtensions]]. It always succeeds for
them since they are born non-extensible.
The major user facing change here is the possibility that
Object.preventExtensions will through if the object can not be made
non-extensible. This wasn't specified in ES5, but I'm ok making that change.
3) It would be really useful if Reflect.preventExtensions returned the
boolean success code, as this provides an easier way to test if this
operation succeeded than is possible with Object.preventExtensions. Compare:
if (Reflect.preventExtensions(obj)) { /* success code */ } else { /* failure
code */ }
vs.
try {
Object.preventExtensions(obj);
/* success code */
} catch (e) { if (!(e instanceof TypeError)) throw e; // not even a
fool-proof test
/* failure code */
}
OK, [[PreventExtensions]] not returns a boolean
* [[Delete]]: I would remove because its [[Configurable]] attribute is
false. from the description. Proxies and host objects may return false for
other reasons as well (cf. the recent discussions about DontDelete vs.
configurable:false)
Do you have some alternative wording? These descriptions (along with
whatever eventually goes into 8.1.6.3) are intended to be the informal
description of the contract of these MOP methods. What is true or false
actually intended to mean for [[Delete]]? Is it that false means: the
property exists but the property wasn't deleted?
The success code for [[Delete]] is indeed fuzzy as it may mean:
a) the property was/was not successfully deleted
b) the property is / is no longer present
Since deleting a non-existent property returns true, b) is closer to the
existing semantics.
Here's my alternative wording:
[[Delete]] (propertyKey) - Boolean: Removes the own property indentified by
the propertyKey parameter from the object. Return false if the property was
not deleted and is still present. Return true if the property was deleted or
was not present.
Good, I'll use that language.
Allen
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
Then it naturally follows that you can as well do `let {must:must,
?may:may} = o` which can be shortened.
Yes, that was the syntax we talked about earlier this year, but I think
CoffeeScript and TypeScript make a case for suffix-?.
And it can go deeper, since it is Nil.
What is Nil? There is no requirement with ? in the pattern language (on
the LHS) for the RHS to be of any particular type.
I like Nil, and it may help rescue ?. the existential operator strawman.
But that is in the expression language, not in the pattern language.
I like not to make things unnecessarily disjoint. Here I see the
possibility of having pattern language (in future patterns as well as
in present destructuring) having same semantics as the expression
language _with_throwing_on_nonexistent_property_ (that is what you
asked in this thread, unless I did not understand).
I'm with you on wanting equivalences, such that same semantics works
up to some limit (proxies, perhaps -- I'm not sure). Since
pattern-matching is in the future it is possible it could diverge
observably from equivalent expression language, for good reason.
If there's no reason in the future to diverge, great.
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
That is, these are identical, except the syntax:
r = o.p.q{p: {q: r}} = o
r = o.?p.q{?p: {q: r}} = o
P=o.p; Q=o.?q{p: P, ?q: Q} = o
Here I part company only on syntax:
r = o?.p.q {p?: {q: r}} = o
P=o.p; Q=o?.q{p: P, q?: Q} = o
And of course, the short-hand works:
p=o.p; q=o?.q{p, q?} = o
With it can go deeper, since it is Nil I meant the second line,
where (o.?p) produces Nil, so o.?p.q being Nil.q produces Nil as well,
without throw.
Yes, I agree (already :-P) that this is a good idea for saving the
existential operator.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Just for fun and to experiment with, I added nil to Continuum to play
around with. It's similar to the one I made for V8, but a bit more
complete. It coerces to the empty string or 0, is callable and
constructable (returns self), returns self for all property access, has no
prototype, is typeof 'undefined', and falsey. You can access via:
import { nil } from '@continuum';
At http://benvie.github.com/continuum
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
I like Nil, and it may help rescue ?. the existential operator strawman.
But that is in the expression language, not in the pattern language.
I like not to make things unnecessarily disjoint. Here I see the
possibility of having pattern language (in future patterns as well as
in present destructuring) having same semantics as the expression
language _with_throwing_on_nonexistent_property_ (that is what you
asked in this thread, unless I did not understand).
I'm with you on wanting equivalences, such that same semantics works
up to some limit (proxies, perhaps -- I'm not sure). Since
pattern-matching is in the future it is possible it could diverge
observably from equivalent expression language, for good reason.
If there's no reason in the future to diverge, great.
In the short example you sketched, with case {must, ?may} there is no
need to diverge from the destructuring; so I did not even imagine such
divergence for the moment.
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing, [[Call]]
return Nil. But there are sure some nasty details down there.
That is, these are identical, except the syntax:
r = o.p.q {p: {q: r}} = o
r = o.?p.q {?p: {q: r}} = o
P=o.p; Q=o.?q {p: P, ?q: Q} = o
Here I part company only on syntax:
r = o?.p.q {p?: {q: r}} = o
P=o.p; Q=o?.q {p: P, q?: Q} = o
And of course, the short-hand works:
p=o.p; q=o?.q {p, q?} = o
Well, if it must be this way. I mentally joined the ? with the dot where
the operation occurs... but now that I think of it, it doesn't matter if
it is take o, take its p and make it Nil if nonexistent, take its q
early nilling of mine and take o, take its p, make it Nil if nullCo.,
take its q postponed nilling of yours.
I feared it could make mental errors, but it will not.
With it can go deeper, since it is Nil I meant the second line,
where (o.?p) produces Nil, so o.?p.q being Nil.q produces Nil as well,
without throw.
Yes, I agree (already :-P) that this is a good idea for saving the
existential operator.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brandon Benvie wrote:
Just for fun and to experiment with, I added nil to Continuum to play
around with. It's similar to the one I made for V8, but a bit more
complete. It coerces to the empty string or 0, is callable and
constructable (returns self), returns self for all property access, has
no prototype, is typeof 'undefined', and falsey. You can access via:
I should also `== null` and `== undefined`.
import { nil } from '@continuum';
At http://benvie.github.com/continuum
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Oh yeah forgot to mention that, but it does that too. Does not === either
(as I think would be desired).
On Wed, Jan 2, 2013 at 1:30 PM, Herby Vojčík he...@mailbox.sk wrote:
Brandon Benvie wrote:
Just for fun and to experiment with, I added nil to Continuum to play
around with. It's similar to the one I made for V8, but a bit more
complete. It coerces to the empty string or 0, is callable and
constructable (returns self), returns self for all property access, has
no prototype, is typeof 'undefined', and falsey. You can access via:
I should also `== null` and `== undefined`.
import { nil } from '@continuum';
At http://benvie.github.com/**continuumhttp://benvie.github.com/continuum
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
For comparison, here's the internal methods that I currently have
implemented, which line up with what you said.
https://github.com/Benvie/continuum/blob/gh-pages/engine/object-model/%24Nil.js#L105
On Wed, Jan 2, 2013 at 1:28 PM, Herby Vojčík he...@mailbox.sk wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
I like Nil, and it may help rescue ?. the existential operator strawman.
But that is in the expression language, not in the pattern language.
I like not to make things unnecessarily disjoint. Here I see the
possibility of having pattern language (in future patterns as well as
in present destructuring) having same semantics as the expression
language _with_throwing_on_nonexistent_**property_ (that is what you
asked in this thread, unless I did not understand).
I'm with you on wanting equivalences, such that same semantics works
up to some limit (proxies, perhaps -- I'm not sure). Since
pattern-matching is in the future it is possible it could diverge
observably from equivalent expression language, for good reason.
If there's no reason in the future to diverge, great.
In the short example you sketched, with case {must, ?may} there is no need
to diverge from the destructuring; so I did not even imagine such
divergence for the moment.
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing, [[Call]]
return Nil. But there are sure some nasty details down there.
That is, these are identical, except the syntax:
r = o.p.q {p: {q: r}} = o
r = o.?p.q {?p: {q: r}} = o
P=o.p; Q=o.?q {p: P, ?q: Q} = o
Here I part company only on syntax:
r = o?.p.q {p?: {q: r}} = o
P=o.p; Q=o?.q {p: P, q?: Q} = o
And of course, the short-hand works:
p=o.p; q=o?.q {p, q?} = o
Well, if it must be this way. I mentally joined the ? with the dot where
the operation occurs... but now that I think of it, it doesn't matter if it
is take o, take its p and make it Nil if nonexistent, take its q early
nilling of mine and take o, take its p, make it Nil if nullCo., take its
q postponed nilling of yours.
I feared it could make mental errors, but it will not.
With it can go deeper, since it is Nil I meant the second line,
where (o.?p) produces Nil, so o.?p.q being Nil.q produces Nil as well,
without throw.
Yes, I agree (already :-P) that this is a good idea for saving the
existential operator.
/be
Herby
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
On Wed, Jan 2, 2013 at 1:13 PM, Brendan Eich bren...@mozilla.com wrote:
Here I part company only on syntax:
r = o?.p.q {p?: {q: r}} = o
P=o.p; Q=o?.q{p: P, q?: Q} = o
And of course, the short-hand works:
p=o.p; q=o?.q{p, q?} = o
I love this. +1000.
As I've said previously, I think pattern matching would pair exceptionally
well with EcmaScript, and refutable destructuring is a great first step
towards that. After a little bit of use, I expect the community to demand
it, even if they aren't familiar with it in other languages.
I want to destructure here, but I have a couple of possible options. If
only there was some kind of switch case with pattern matching...
No chance of getting pattern matching in for ES6 by any chance, is there? ;)
- Russ
/be
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Interpreted this way, any additional irrefutable markers in a subtree
under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree under
an _irrefutable_ identifier become redundant, correct?
r = o?.p?.q{ p?: { q?: r } } = o
Using Nil, the q in all cases is present (evaluating to Nil), so the
? in q? has no effect. Is that right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?
For the proposal to use Nil for the expression semantics, yes.
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
but o.p doesn't have a q.
On second look this is not as bad as I thought. It would be bad if r
were not bound (so an outer r could become visible) depending on o's
dynamics. That seems right out!
/be
r = o?.p?.q{ p?: { q?: r } } = o
Using Nil, the q in all cases is present (evaluating to Nil),
so the ? in q? has no effect. Is that right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Kevin Smith wrote:
Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?
For the proposal to use Nil for the expression semantics, yes.
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).
but o.p doesn't have a q.
On second look this is not as bad as I thought. It would be bad if r
were not bound (so an outer r could become visible) depending on o's
dynamics. That seems right out!
/be
r = o?.p?.q { p?: { q?: r } } = o
Using Nil, the q in all cases is present (evaluating to Nil),
so the ? in q? has no effect. Is that right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
Brendan Eich wrote:
Kevin Smith wrote:
Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?
For the proposal to use Nil for the expression semantics, yes.
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).
I don't think we should multiply risk by coupling destructuring (which
is in ES6) to Nil (an unproposed strawman) at this point.
In theory and ignoring schedule and order of work, we could, and doing
so has some symmetry (or really some duality) with a Nil-under-the-hood
for ?. as existential operator. This is not a strong motivation in my view.
Also, would you really produce nil not undefined only for patterns where
? was used and the pattern irrefutably succeeded because of a missing
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW
let {p: {q?: r}} = {p: {s: 42}};
binds r to nil, while
let r = {p: {s: 42}}.r;
of course binds r to undefined? That seems undesirable.
*If* we agree to put nil in the language (ideally as a stdlib component,
self-hosted or self-hostable), then we need to be careful about where it
is observable. Just because one could use it under the hood to implement
?. does not mean it should be the result of ?-pattern default-matching.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote: To tolerate o = null and o = undefined (which is not what o.p?.q does), the equivalence would be: I forgot to avoid the other slop, implicit ToObject conversion. Correcting: To tolerate primitive type value in o (which is not what o.p?.q does), the equivalence would be: /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Brendan Eich wrote:
To tolerate o = null and o = undefined (which is not what o.p?.q
does), the equivalence would be:
I forgot to avoid the other slop, implicit ToObject conversion.
Correcting:
To tolerate primitive type value in o (which is not what o.p?.q
does), the equivalence would be:
Er, strike that -- not what CoffeeScript does, not wanted.
But this raises an issue: should ? applied to the whole object (o?.p in
expression, {p:q}? = o in pattern language) also cause an implicit
ToObject(o)?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
Kevin Smith wrote:
Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?
For the proposal to use Nil for the expression semantics, yes.
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).
I don't think we should multiply risk by coupling destructuring (which
is in ES6) to Nil (an unproposed strawman) at this point.
In theory and ignoring schedule and order of work, we could, and doing
so has some symmetry (or really some duality) with a Nil-under-the-hood
for ?. as existential operator. This is not a strong motivation in my view.
Also, would you really produce nil not undefined only for patterns where
? was used and the pattern irrefutably succeeded because of a missing
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW
let {p: {q?: r}} = {p: {s: 42}};
binds r to nil, while
let r = {p: {s: 42}}.r;
You meant let r = {p: {s: 42}}.p.q?, didn't you?
This binds r to nil as well.
of course binds r to undefined? That seems undesirable.
Yes. But one of the problems mentioned on this thread was ARB's It's
not composable.
With internal-nil-exposed-undefined, these are different:
(p.q?).r
p.q?.r
With nil-reified, those are identical.
*If* we agree to put nil in the language (ideally as a stdlib component,
self-hosted or self-hostable), then we need to be careful about where it
is observable. Just because one could use it under the hood to implement
?. does not mean it should be the result of ?-pattern default-matching.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
Kevin Smith wrote:
Interpreted this way, any additional irrefutable markers in a
subtree under a refutable identifier become redundant, correct?
Er, meant this:
Interpreted this way, any additional irrefutable markers in a subtree
under an _irrefutable_ identifier become redundant, correct?
For the proposal to use Nil for the expression semantics, yes.
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).
I don't think we should multiply risk by coupling destructuring (which
is in ES6) to Nil (an unproposed strawman) at this point.
In theory and ignoring schedule and order of work, we could, and doing
so has some symmetry (or really some duality) with a Nil-under-the-hood
for ?. as existential operator. This is not a strong motivation in my
view.
Also, would you really produce nil not undefined only for patterns where
? was used and the pattern irrefutably succeeded because of a missing
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW
let {p: {q?: r}} = {p: {s: 42}};
binds r to nil, while
let r = {p: {s: 42}}.r;
You meant let r = {p: {s: 42}}.p.q?, didn't you?
Er, yes! Sorry about that.
This binds r to nil as well.
Confusion. Let me write it out to be sure we are talking about the same
thing:
let r = {p: {s: 42}}.p.q;
binds nil to r? That's not backward compatible.
of course binds r to undefined? That seems undesirable.
Yes. But one of the problems mentioned on this thread was ARB's It's
not composable.
s/composable/compositional/
That was about CoffeeScript's semantics based on transcompilation, which
I showed a few messages back. From Andreas's comments as captured in the
minutes:
ARB: This is non-compositional
o = {}
r = o?.p.q.r
r = (o?.p).q.r
r = o?.p.q.r()
Results in…
var o, r;
o = {};
r = o != null ? o.p.q.r : void 0;
r = (o != null ? o.p : void 0).q.r;
r = o != null ? o.p.q.r() : void 0;
Non-starter.
With internal-nil-exposed-undefined, these are different:
(p.q?).r
p.q?.r
With nil-reified, those are identical.
Yes, I already agreed (three times :-|) that nil rescues ?. from the
condemnation ARB heaped on the CoffeeScript semantics.
That's not relevant to what we were just arguing about though: whether
nil rather than undefined should be an observable result of either
destructuring or (you seemed to say just above) property gets on plain
old objects!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does but
o.p doesn't have a q.
So as Nil cascades downward, it essentially converts the whole subtree to a
deeply irrefutable pattern.
On second look this is not as bad as I thought. It would be bad if r were
not bound (so an outer r could become visible) depending on o's dynamics.
That seems right out!
Yes, let's lobbest thy holy hand grenade at that one.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote: Yes, I already agreed (three times :-|) that nil rescues ?. from the condemnation ARB heaped on the CoffeeScript semantics. That's not relevant to what we were just arguing about though: whether nil rather than undefined should be an observable result of either destructuring or (you seemed to say just above) property gets on plain old objects! Apologies, I did not make the full idea clear: You want nil in the language and observable via desugaring o.?p.q == (o.p == null ? nil : o.p).q without re-evaluating o.p of course (and using the syntax you showed). Furthermore, in the case where o.p == null, the result is nil.q which is nil. (Please correct me if I am wrong on any of this! Appreciate the discussion here.) What I would like to do: spec ?. without exposing nil. Perhaps this is not possible but I think it is, since we can make the definite semantics for o.?p.q or whatever syntax we want (I advocate o.p?.q) do a final censoring act that converts nil back to undefined. You could be right that we want nil and ?. together -- no way to decouple risk. I'm not seeing that argument yet. People want ?. yesterday, nil not so much (see twitter). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
You're right, this implies destructuring binding forms behave in a
way that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that
does but o.p doesn't have a q.
So as Nil cascades downward, it essentially converts the whole subtree
to a deeply irrefutable pattern.
I would rather recast this into the expression language from the pattern
language before invoking most-holy Nil :-P.
console.log({p: {q: 42}}.p?.q);
logs 42, while
console.log({p: {s: 42}}.p?.q);
would log undefined which could be nil in disguise, or not (see my
previous post to this one).
Destructuring with the opt-in irrefutable syntax, suffix-? is my
preference, does not seem to me to involve Nil in its explanation or
semantics.
Sorry to be a stickler. I do not want to couple destructuring to exposed
Nil.
On second look this is not as bad as I thought. It would be bad if
r were not bound (so an outer r could become visible) depending on
o's dynamics. That seems right out!
Yes, let's lobbest thy holy hand grenade at that one.
:-)
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
You're right, this implies destructuring binding forms behave in a way
that I flagged as possibly not wanted:
let {p?: {q: r}} = o;
would bind r to undefined for any o that doesn't have a p or that does
In my view it binds to Nil (but it is falsey, == null etc., typeof
'undefined' so it should work).
I don't think we should multiply risk by coupling destructuring (which
is in ES6) to Nil (an unproposed strawman) at this point.
In theory and ignoring schedule and order of work, we could, and doing
so has some symmetry (or really some duality) with a Nil-under-the-hood
for ?. as existential operator. This is not a strong motivation in my
view.
Also, would you really produce nil not undefined only for patterns where
? was used and the pattern irrefutably succeeded because of a missing
property, and otherwise (no ?-pattern involved) bind r to undefined? IOW
let {p: {q?: r}} = {p: {s: 42}};
binds r to nil, while
let r = {p: {s: 42}}.r;
You meant let r = {p: {s: 42}}.p.q?, didn't you?
Er, yes! Sorry about that.
This binds r to nil as well.
Confusion. Let me write it out to be sure we are talking about the same
thing:
let r = {p: {s: 42}}.p.q;
binds nil to r? That's not backward compatible.
Sorry, I did wrote it so it could lead to confusion.
Let me try to explain better.
(1) let {p: {q?: r}} = {p: {s: 42}};
// me: r = Nil, you: ???, probably undefined
(2) let r = {p: {s: 42}}.p.q?;
// me: r = Nil, you: ???, probably undefined
(3) let {p: {q: r}} = {p: {s: 42}};
// r = undefined (of course)
(4) let r = {p: {s: 42}}.p.q;
// r = undefined (of course)
You compared (1) to (4). I would it is comparing apples to oranges, and
that (1) and (2) or (3) and (4) should be compared.
Yes. But one of the problems mentioned on this thread was ARB's It's
not composable.
s/composable/compositional/
That was about CoffeeScript's semantics based on transcompilation, which
I showed a few messages back. From Andreas's comments as captured in the
minutes:
ARB: This is non-compositional
o = {}
r = o?.p.q.r
r = (o?.p).q.r
r = o?.p.q.r()
Results in…
var o, r;
o = {};
r = o != null ? o.p.q.r : void 0;
r = (o != null ? o.p : void 0).q.r;
r = o != null ? o.p.q.r() : void 0;
Non-starter.
With internal-nil-exposed-undefined, these are different:
(p.q?).r
p.q?.r
With nil-reified, those are identical.
Yes, I already agreed (three times :-|) that nil rescues ?. from the
condemnation ARB heaped on the CoffeeScript semantics.
Sorry, I wasn't after this. It just seems there are still some
misunderstadings...
That's not relevant to what we were just arguing about though: whether
nil rather than undefined should be an observable result of either
Now I am confused.
For (p.q?).r to be same as p.q?.r, (p.q?) must return reified Nil, not
undefined. I was at the impression you say Nil at the background, but
whenever it becomes observable, it should be changed to undefined. That
means p.q? returns undefined, and (p.q?).r fails.
Or do you mean (1) and (2) from above are not to be equivalant ((1) Nil,
(2) undefined)?
Or something completely different?
destructuring or (you seemed to say just above) property gets on plain
old objects!
No, that was a misunderstanding.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote: Brendan Eich wrote: Yes, I already agreed (three times :-|) that nil rescues ?. from the condemnation ARB heaped on the CoffeeScript semantics. That's not relevant to what we were just arguing about though: whether nil rather than undefined should be an observable result of either destructuring or (you seemed to say just above) property gets on plain old objects! Apologies, I did not make the full idea clear: You want nil in the language and observable via desugaring o.?p.q == (o.p == null ? nil : o.p).q without re-evaluating o.p of course (and using the syntax you showed). Furthermore, in the case where o.p == null, the result is nil.q which is nil. (Please correct me if I am wrong on any of this! Appreciate the discussion here.) No, now it is exactly how it was meant. What I would like to do: spec ?. without exposing nil. Perhaps this is not possible but I think it is, since we can make the definite semantics for o.?p.q or whatever syntax we want (I advocate o.p?.q) do a final censoring act that converts nil back to undefined. You could be right that we want nil and ?. together -- no way to decouple risk. I'm not seeing that argument yet. People want ?. yesterday, nil not so much (see twitter). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote:
In the short example you sketched, with case {must, ?may} there is no
need to diverge from the destructuring; so I did not even imagine such
divergence for the moment.
Should a proxy in the head of a match be able to observe case-by-case
refutation?
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing,
[[Call]] return Nil. But there are sure some nasty details down there.
Yeah, this is unsafe by design, if the spec has a bug then Nil leaks
out. Want undefined in ES6, not Nil.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
[Trimming overcited top text.]
Herby Vojčík wrote:
Confusion. Let me write it out to be sure we are talking about the same
thing:
let r = {p: {s: 42}}.p.q;
binds nil to r? That's not backward compatible.
Sorry, I did wrote it so it could lead to confusion.
Let me try to explain better.
(1)let {p: {q?: r}} = {p: {s: 42}};
// me: r = Nil, you: ???, probably undefined
Yes. For the reason I gave: destructuring in ES6 cannot depend on Nil,
but I argue should include irrefutable opt-in via suffix-?.
(2)let r = {p: {s: 42}}.p.q?;
// me: r = Nil, you: ???, probably undefined
Yes, undefined. For the reason I gave, not coupling too much among ES7
or later straw proposals.
(3)let {p: {q: r}} = {p: {s: 42}};
// r = undefined (of course)
No issue, great.
(4)let r = {p: {s: 42}}.p.q;
// r = undefined (of course)
No issue, great. Whew!
You compared (1) to (4). I would it is comparing apples to oranges,
and that (1) and (2) or (3) and (4) should be compared.
Apologies, on re-reading I see I misread your trailing '?' after 'q' in
You meant let r = {p: {s: 42}}.p.q?, didn't you?
That's not relevant to what we were just arguing about though: whether
nil rather than undefined should be an observable result of either
Now I am confused.
For (p.q?).r to be same as p.q?.r, (p.q?) must return reified Nil, not
undefined. I was at the impression you say Nil at the background, but
whenever it becomes observable, it should be changed to undefined.
That means p.q? returns undefined, and (p.q?).r fails.
Obviously I don't want these different parenthesizations to fail. I
believe we can spec the semantics such that InternalNil, just like
ES1-6's Reference type, is not observable.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Brendan Eich wrote:
Herby Vojčík wrote:
In the short example you sketched, with case {must, ?may} there is no
need to diverge from the destructuring; so I did not even imagine such
divergence for the moment.
Should a proxy in the head of a match be able to observe case-by-case
refutation?
I'd say no, it should be done transparently be the language itself, via
that (foo==null?nil:foo) desugaring. But that's mostly a feeling (the
question is, how to whether foo==null is done by some shortcut without
actually getting foo, proxy may then observe that shortcut).
We need to detail how Nil works, how it cannot be wrapped or observed,
etc. in order to maintain equivalence.
In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing,
[[Call]] return Nil. But there are sure some nasty details down there.
Yeah, this is unsafe by design, if the spec has a bug then Nil leaks
out. Want undefined in ES6, not Nil.
I don't understand the unsafety. If Nil is observable part of the
language, then this is natural semantics. If it should be hidden, that's
another story.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Herby Vojčík wrote: We need to detail how Nil works, how it cannot be wrapped or observed, etc. in order to maintain equivalence. In my naive view, [[GetP]] returns Nil, [[SetP]] does nothing, [[Call]] return Nil. But there are sure some nasty details down there. Yeah, this is unsafe by design, if the spec has a bug then Nil leaks out. Want undefined in ES6, not Nil. I don't understand the unsafety. If Nil is observable part of the language, then this is natural semantics. If it should be hidden, that's another story. I assumed from context (cited above) that you were talking about destructruing in ES6. That spec lacks Nil as an observable and must censor any internal Nil specification type. Could be done, but I argue it's safer to leave [[GetP]] etc. dealing in undefined for now. Of course if we want Nil in the language, then full speed ahead! That would be later (ES7 or above), if ever. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A Variation on ES Modules
I have added few comments to https://gist.github.com/4382710
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Friday, 2012-12-28 at 10:21 , Kevin Smith wrote:
Just to finalize this thread, I updated the gist based on comments from
Andreas:
https://gist.github.com/4382710
It includes syntax for proper inline modules, and an extension syntax for
pre-loading (aka concatenating). It also brings the syntax for module
aliasing closer to the previous harmony proposal:
module M = m.js;
module N = M.N;
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org (mailto: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
RE: excluding features from sloppy mode
I was already looking into something similar so I checked my dataset of scripts
from 2235 sites and found only one example of duplicate identifier names:
vnexpress.net. Here's the decl
function
GetTopicHTML(sId,sTitle,sDate,sPath,sType,sPath,arItem,vType1,vType2,vCustomTitle,vShowHeader){
Notice sPath is duplicated. However, sPath is subsequently never used at all,
so I'm not sure what the intent was here. Possibly just a bug or cruft.
That said, _ is being used to ignore parameters on 36 sites. Most commonly this
is jQuery library usage (ignoring the first index parameter of forEach, for
example) but a good number of other examples exist. I can provide more details
if people are interested.
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, December 29, 2012 7:10 PM
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen that in JS. In ML, sure.
Have you any links to cite?
/be
___
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
Re: Property descriptor normalization (Was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))
On Dec 31, 2012, at 3:37 AM, Tom Van Cutsem wrote:
2012/12/30 Allen Wirfs-Brock al...@wirfs-brock.com
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
* I'm a bit uncomfortable with the removal of property descriptor
normalization in the getOwnPropertyDescriptor/defineProperty traps.
Especially for getOwnPropertyDescriptor I think it's a breaking change w.r.t.
ES5.1.
[...]
This permits things like:
Object.defineOwnProperty(pObj1,foo, {method: func}); //define property on
a proxy-based object, that have method properties
console.log (Object.getOwnPropertyDescriptor(pObj1,foo).method);//we
can retrieve the value of the method attribute (if the proxy supports it)
Object.defineOwnProperty(pObj2,foo,Object.getOwnProperty(pObj1, foo));
//copy a method properry from pObj1 to pObj2
If descriptor object with extended attributes is applied to an ordinary
object, it is always first internally converted to a PD record. PD records
only contain fields for the ordinary attributes, and any operations upon
ordinary objects will have no visibility of the extended attributes.
Yes, I agree to all of this and I understand this is the intent of the new
[[Origin]] field of internal property descriptors.
I also agree there's no problem for normal objects, which continue to always
cons a fresh property descriptor object.
The only breaking change (relative to ES 5.1) possibility I see must start
with the assumption that ES5.1 property attributes are the final definition
of property descriptor objects and that additional property attributes can
never be added to the language (by the spec., not just via proxies) using any
of the pre-existing ES5.1 APIs. That seems quite unreasonable and was
certainly not the intent when we introduced the reflection API into ES5. [...]
This was not the breaking change I had in mind and I agree with you that
adding new attributes is both useful and supported by the ES5.1 design.
Here's the breaking change I had in mind:
var propDescMap = {};
var proxy = Proxy({}, {
defineProperty(target, name, desc) { propDescMap[name] = desc; return true;
},
getOwnPropertyDescriptor(target, name) { return propDescMap[name]; }
};
// client1 adds:
var pd1 = {
get configurable() { return Math.random() 0.5; }, // return true or
false, randomly
custom: true
};
Object.defineProperty(proxy, foo, pd1);
// client2 queries:
var pd2 = Object.getOwnPropertyDescriptor(proxy, foo);
If I understand correctly, pd2 now refers to exactly the same object as pd1,
preserving the custom attribute.
Note that you don't need to start with the defineProperty call using pd1 to get
the following effects. The same observable behavior could occur just by
defining the getOwnPropertyDescriptor trap to directly construct and return a
similar value for pd2.
However, this semantics also implies that:
1) pd2 is not a completed property descriptor, lacking a writable/enumerable
attribute. Only the internal property descriptor was fully completed, not the
[[Origin]] object.
We can't say what complete means for a property descriptor containing custom
attributes. Just like the complete PD for an ordinary accessor property
doesn't contain a writable property, perhaps a PD for an exotic custom
property only have configurable and custom attributes. This is all up to
the designer of the exotic property and something they should define when they
describe the contract of their exotic object.
Yes, the internal PD record will be completed but it is only used for a
sequence of pseudo-code algorithm steps. I don't currently see any place where
the internal PD record is used in such a way that we have any problems. Of
course, the proxy itself should provide consistent
Get/Set/defineProperty/getOwnPropertyDescriptor behavior for such exotic
properties. If it doesn't its a ES programmer level bug.
2) pd2.configurable is not a data property, but may change randomly
So? That's the nature of accessor properties although it's not how they are
normally used. Why are these values being unstable any worse than any others?
The one thingI can imagine is that a proxy author could use an configurable
attribute accessor to sneak past the configurable invariant check in Proxy
[[GetOwnProperty]]. I can imagine that we might want to normalize the
configurable property (only for the situation where their is a corresponding
target property??) of the descriptor object, but no other properties.
3) since pd1/pd2 refers to a mutable object, changes made by client1 will be
visible to client2 and vice-versa.
Again, this is the nature of programming with object references. If the Proxy
wants to prevent this, it shouldn't store the descriptor objects -- just like
the spec. doesn't store the PD record that is used to create a property. If
client2 is worried about this and doesn't trust the Proxy (in which case it
probably
Re: excluding features from sloppy mode
This is good evidence to have, thanks.
It still doesn't mean that, for any such content whose owner decides to
change a parameter to use destructuring, we can't link a ban on
duplicate formals with that destructuring opt-in-by-its-own-new-syntax
in ES6 sloppy mode. It's nowhere near enough duplicate formal usage to
give me pause, at any rate.
Anyone maintaining these functions might rather find out about
unintended duplicates!
/be
Brian Terlson wrote:
I was already looking into something similar so I checked my dataset of scripts
from 2235 sites and found only one example of duplicate identifier names:
vnexpress.net. Here's the decl
function
GetTopicHTML(sId,sTitle,sDate,sPath,sType,sPath,arItem,vType1,vType2,vCustomTitle,vShowHeader){
Notice sPath is duplicated. However, sPath is subsequently never used at all,
so I'm not sure what the intent was here. Possibly just a bug or cruft.
That said, _ is being used to ignore parameters on 36 sites. Most commonly this
is jQuery library usage (ignoring the first index parameter of forEach, for
example) but a good number of other examples exist. I can provide more details
if people are interested.
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, December 29, 2012 7:10 PM
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never seen that in JS. In ML, sure.
Have you any links to cite?
/be
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
The proposed behavior when a non-leaf is marked irrefutable (the entire subtree is essentially irrefutable) seems reasonable to. Unless I'm mistaken, it's also backward compatible with your original leaf-only design, right? If so, irrefutability could be leaf-only in ES6, to be expanded possibly in ES7 along with the existential operator. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
The proposed behavior when a non-leaf is marked irrefutable (the entire subtree is essentially irrefutable) Sorry, should read: The proposed behavior when a non-leaf is marked irrefutable (the entire subtree imputes undefined when triggered) ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
I think we can do this now. Allen should weigh in. Hope to hear from Andreas R. soon too! Apologies for the long thread, and thanks to Herby for interaction that clarified many things. Perhaps I should resummarize: The best new-new plan to avoid adding slop is to revise ES6 destructuring thus: 1. No ToObject(RHS). 2. Exception on missing property selected without a ?-suffix. 3. ?-suffix allowed on any pattern, imputing undefined deeply instead of refuting. 4: the ? is a separate lexeme from the : in long-hand patterns. How's that? /be Kevin Smith wrote: The proposed behavior when a non-leaf is marked irrefutable (the entire subtree is essentially irrefutable) Sorry, should read: The proposed behavior when a non-leaf is marked irrefutable (the entire subtree imputes undefined when triggered) ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Return values of mutating MOP operations (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))
2013/1/2 Allen Wirfs-Brock al...@wirfs-brock.com
Symbols don't need to fail on [[PreventExtensions]]. It always succeeds
for them since they are born non-extensible.
Sounds reasonable.
The major user facing change here is the possibility that
Object.preventExtensions will through if the object can not be made
non-extensible. This wasn't specified in ES5, but I'm ok making that
change.
Ok. Recall that in the old Proxy API, we already had the fix() trap
returning a boolean, and Object.{preventExtensions,seal,freeze} throwing on
false.
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
