On 21 April 2012 11:56, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
Of course, it is absolutely true that the same argument can be made
about someExpression.x, but I file that under historic legacy. If we
were to design JS from scratch -- and with the ES6 feature set! --
then
On Apr 23, 2012, at 2:40 AM, Andreas Rossberg wrote:
On 21 April 2012 11:56, Herby Vojčík he...@mailbox.sk wrote:
...
JS model _is_ about sloppy semantics (I do not call it sloopy, I'd rather
called it liberal), that is, undefined if not present.
It's a term sometimes used on TC39, I
On 21 April 2012 01:08, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are almost exactly the same
Andreas Rossberg wrote:
On 21 April 2012 01:08, Brendan Eichbren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are
Andreas Rossberg wrote:
Clearly, it's not
possible to correct that, but why should that imply that all new
features need to inherit sloppy semantics, too?
There's no strict logical implication. On the plus side, the new
features are stricter (if you are pro-strict and anti-sloppy -- let's
On 20 April 2012 02:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 19, 2012, at 4:16 PM, David Herman wrote:
let { unidentifiedAdult: mom as dad, unidentifiedChild: sister as brother
}
or
let { undentifiedAdult as mom as dad, unidentifiedChild as sister as
brother }
I
Andreas Rossberg wrote:
I disagree. That is a bogus analogy. An object pattern is completely
different from a 'let'. In particular, the latter binds 'mom', but not
'dad' and 'auntie'. The proper equivalence (I wouldn't call it a
duality)
Right. The duality I've cited is between
let o = {p:
On Apr 20, 2012, at 2:16 AM, Andreas Rossberg wrote:
On 20 April 2012 02:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 19, 2012, at 4:16 PM, David Herman wrote:
let { unidentifiedAdult: mom as dad, unidentifiedChild: sister as
brother }
or
let { undentifiedAdult as
Andreas Rossberg wrote:
On 20 April 2012 17:12, Brendan Eichbren...@mozilla.org wrote:
But is it unthinkable to have 'as' (compositional of course) in the
pattern language only?
Perhaps, but what exactly do you mean? ;)
Patterns can have custom grammar in binding contexts (after let, in
On 20 April 2012 17:53, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 20, 2012, at 2:16 AM, Andreas Rossberg wrote:
On 20 April 2012 02:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 19, 2012, at 4:16 PM, David Herman wrote:
let { unidentifiedAdult: mom as dad,
On 20 April 2012 18:18, Brendan Eich bren...@mozilla.org wrote:
Patterns can have custom grammar in binding contexts (after let, in catch
heads, etc.), whereas in an assignment expression's left-hand side we'd need
ObjectLiteral and ArrayLiteral to cover the grammar.
I sense trouble trying to
Andreas Rossberg wrote:
Honestly, my
feeling is that strictly sticking to that principle will overly
constrain pattern syntax anyway, if not for 'as' then for the next
nice feature. I dimly remember that we had it coming up before.
Dave and I were talking about making fail-soft or irrefutable
Brendan Eich wrote:
Dave suggested making the first case, let {x} = {}, throw, and
requiring ? as a pattern modifier (I suggested prefix):
let {?x} = {}; // x is undefined, no throw
let {y} = {}; // throw
I forgot to mention something Dave noticed. Should
let {?x:{y}} = {};
This too
Brendan Eich wrote:
Should
let {?x:{y}} = {};
I lost a line finishing the obvious Should ... throw? question.
We could make ? shallow and require another ?-prefix to avoid the throw:
let {?x:{?y}} = {}
but that seems like it might be user-hostile.
CoffeeScript has ?. and ?( fail-soft
On Apr 20, 2012, at 2:22 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
Honestly, my
feeling is that strictly sticking to that principle will overly
constrain pattern syntax anyway, if not for 'as' then for the next
nice feature. I dimly remember that we had it coming up before.
Dave
Allen Wirfs-Brock wrote:
js let {y:{z}} = {};
typein:4: TypeError: (void 0) is undefined
alternatively:
let {y:{z} = {z:default}} = {};
or
let {y:{z = default}} = {};
Too verbose, for one.
(Atrocious SpiderMonkey failure to pretty-print the blamed expression
instead of
On Apr 20, 2012, at 2:43 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
js let {y:{z}} = {};
typein:4: TypeError: (void 0) is undefined
alternatively:
let {y:{z} = {z:default}} = {};
or
let {y:{z = default}} = {};
Too verbose, for one.
(Atrocious SpiderMonkey
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are almost exactly the same thing. They both establish a hoisted
uninitialized lexical binding
On 19 April 2012 00:45, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 18, 2012, at 2:48 PM, Brendan Eich wrote:
David Herman wrote:
*Please*, let's do this right.
This says to me (what I originally expected) that duplicate property name at
any ply in an object pattern should be an
On Apr 18, 2012, at 2:48 PM, Brendan Eich wrote:
David Herman wrote:
*Please*, let's do this right.
This says to me (what I originally expected) that duplicate property name at
any ply in an object pattern should be an early error.
Anyone disagree?
I got as far as being ready to type
On Apr 19, 2012, at 2:18 PM, Allen Wirfs-Brock wrote:
//initialize some variable with default objects
let {
unidentifedAdult: mom,
unidetifiedAdult: dad,
unidentiedChild: brother,
unidentifiedChild: sister
} = peopleConstants;
why is this less desirable than:
We've supported destructuring for years and no one has asked for this. I
say YAGNI and when in doubt, leave it out. One can always write two
destructuring declarations without much repetition:
let {b} = obj;
let {x,y} = b;
but of course one would just write
let {x, y} = obj.b;
in that
On Wed, Apr 18, 2012 at 11:26 AM, Brendan Eich bren...@mozilla.org wrote:
We've supported destructuring for years and no one has asked for this. I
say YAGNI and when in doubt, leave it out. One can always write two
destructuring declarations without much repetition:
But who has been using
David Nolen wrote:
On Wed, Apr 18, 2012 at 11:26 AM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
We've supported destructuring for years and no one has asked for
this. I say YAGNI and when in doubt, leave it out. One can always
write two destructuring
Clearly it has utility. Same with callable object protocols ;-).
The debate is always about whether every useful thing must be included,
when there are long-hands aplenty. This cuts both ways, since
destructuring is mainly an affordance, syntactic sugar.
The other issue here is standardized
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
That looks like a mistake. ES5 strict mode and so 1JS wants duplicate
property names in object literals to be errors, so I expect the same for
duplicate
On 18 April 2012 17:51, Herby Vojčík he...@mailbox.sk wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
That won't work for arrays, for example.
I agree that 'as' patterns (and even more so, wildcard patterns) are
On Wednesday, 2012-04-18 at 08:26 , Brendan Eich wrote:
We've supported destructuring for years and no one has asked for this. I
say YAGNI and when in doubt, leave it out. One can always write two
destructuring declarations without much repetition:
let {b} = obj;
let {x,y} = b;
but
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out of the box (in
FF11 firebug console; just tried), so why include as if it already is
there,
Another option that feels intuitive to me is:
let { a, b: ({ x, y }) } = object;
Parentesis imply that I want both parent and matched children.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Wednesday, 2012-04-18 at 09:01 , Irakli Gozalishvili wrote:
On Wednesday,
Andreas Rossberg wrote:
On 18 April 2012 17:51, Herby Vojčíkhe...@mailbox.sk wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
That won't work for arrays, for example.
Yeah. :-/
Then either not have it or syntax
On Wednesday, 2012-04-18 at 09:02 , Herby Vojčík wrote:
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out of the box (in
On 18 April 2012 18:09, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
On 18 April 2012 17:51, Herby Vojčíkhe...@mailbox.sk wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
That won't work for
Herby Vojčík wrote:
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out of the box
(in FF11 firebug console; just tried), so why include as if it
Irakli Gozalishvili wrote:
OMG, you're right!!! I could swear it did not worked before as I had
unsuccessful attempts to use that form. I guess it's ok if Brendan did
not knew it either :D
I never said I didn't know, I said ES6 new syntax opts into strict mode
for things like banning
On Apr 18, 2012, at 9:29 AM, Brendan Eich wrote:
Herby Vojčík wrote:
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out of the box (in FF11
I've found it quite useful in Clojure/Script and I'm sure folks who have
encountered the feature in the ML derived languages would agree.
Indeed, all of the pattern-match-supporting functional languages
I've used also supported 'as'-patterns in some form ('var@pat' in
Haskell, 'var as pat' in
Irakli Gozalishvili wrote:
I'm sorry for inappropriate comment.
No worries!
My citing Mozilla's experimental JS1.7+ implementation/user-testing
experience is informative, not nearly definitive or anywhere near
normative; somewhat convincing when something is popular, best when we
learned
Allen Wirfs-Brock wrote:
On Apr 18, 2012, at 9:29 AM, Brendan Eich wrote:
Herby Vojčík wrote:
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out
Herby Vojčík wrote:
But, AFAICT, this should be allowed. The 'b:' from destructuring is
Sorry for caps, I don't know why I write it that way... I somehow
automatically held shift because it is an acronym, probably.
___
es-discuss mailing list
On Apr 18, 2012, at 9:49 AM, Allen Wirfs-Brock wrote:
...
var {b,b:{x,y}} = obj; //fine because var declaration static semantics don't
disallow duplicates
{ //avoid any conflicts with the preceeding var
let {b,b:{x,y}} = obj; //block level duplicate declaration
}
You might argue
On Apr 18, 2012, at 10:59 AM, Herby Vojčík wrote:
...
But, AFAICT, this should be allowed. The 'b:' from destructuring is different
from 'b' from let. Is the previous code disallowed in current state?
You're right, I was wrong. See my followup response.
Thanks,
Allen
Allen Wirfs-Brock wrote:
False alarm! Actually the above isn't correct. The current spec draft
actually does allow
let {b,b:{x,y}};
Nice -- is this sufficient to avoid 'as'?
For array patterns we would need to allow property assignments in array
literals:
let [b, 0:{x,y}];
This was
On Apr 18, 2012, at 11:42 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
False alarm! Actually the above isn't correct. The current spec draft
actually does allow
let {b,b:{x,y}};
Nice -- is this sufficient to avoid 'as'?
For array patterns we would need to allow property
Allen Wirfs-Brock wrote:
For array patterns we would need to allow property assignments in array
literals:
let [b, 0:{x,y}] = ...;
This was proposed at one point, IIRC, but a while ago.
Of course, one could destructure like so:
let {0: b, 0: {x, y}} = ...;
It was also
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
For array patterns we would need to allow property assignments in
array literals:
let [b, 0:{x,y}] = ...;
This was proposed at one point, IIRC, but a while ago.
Of course, one could destructure like so:
let {0: b, 0: {x, y}} = ...;
It was
Herby Vojčík wrote:
As was already pointed out, problems are not only _array_
destructurings, but more argument list destructrings, where if you
want to destructure 0-th argument both as b and as {x,y}, you would
need something like that, since you already are inside list, you
cannot opt for
Brendan Eich wrote:
Herby Vojčík wrote:
As was already pointed out, problems are not only _array_
destructurings, but more argument list destructrings, where if you
want to destructure 0-th argument both as b and as {x,y}, you would
need something like that, since you already are inside list,
On Apr 18, 2012, at 1:45 PM, Herby Vojčík wrote:
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
For array patterns we would need to allow property assignments in
array literals:
let [b, 0:{x,y}] = ...;
This was proposed at one point, IIRC, but a while ago.
Of course, one could
Herby Vojčík wrote:
function foo (...args) {
let {0:b, 0:{x,y}, foo, bar, baz} = args;
...
}
That's not right, if you go the long way round you want:
function foo (...args) {
let {0:b, 0:{x,y}, 1:foo, 2:bar, 3:baz} = args;
...
}
but as Allen just suggested, the right
Agreed. This is easy to spec and implement, highly composable (it fits neatly
into the algebra of destructuring patterns everywhere, as opposed to just in
object property-name positions), has no problems with side effects, and does
not violate restrictions that IINM strict mode is supposed to
On Wed, Apr 18, 2012 at 5:35 PM, David Herman dher...@mozilla.com wrote:
Agreed. This is easy to spec and implement, highly composable (it fits
neatly into the algebra of destructuring patterns everywhere, as opposed to
just in object property-name positions), has no problems with side
David Herman wrote:
*Please*, let's do this right.
This says to me (what I originally expected) that duplicate property
name at any ply in an object pattern should be an early error.
Anyone disagree?
/be
___
es-discuss mailing list
On Apr 18, 2012, at 2:48 PM, Brendan Eich wrote:
David Herman wrote:
*Please*, let's do this right.
This says to me (what I originally expected) that duplicate property name at
any ply in an object pattern should be an early error.
Anyone disagree?
I'm not sure that the concern about
54 matches
Mail list logo
