Re: try without catch or finally
On 17 April 2012 22:35, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote:
I'm not sure if this has been discussed before, but is it a terribly bad
idea to make catch/finally optional for a try block?
There's a lot of code like this out there:
try { /* something here */ } catch (e) { /* nothing here */ }
Silent catch-alls like that are almost always bad code. I think the
language rather shouldn't encourage this pattern with extra
convenience.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
I'm sorry, but can somebody explain what the real use case for all this would be? And why proxies do not already cover it? Do we really need to make _every_ object into half a (mutable?) function proxy now? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: try without catch or finally
Silent catch-alls like that are almost always bad code. I think the language rather shouldn't encourage this pattern with extra convenience. I don't see how this would be much more encouraging than allowing for the catch block to do nothing. The people who would use this would leave the catch block empty anyway. I am also perplexed as to how often things are countered with similar arguments. Incompetent programmers make bad decisions regardless of how much the language/framework/library does to prevent this. In my mind it's not a valid excuse for not making things harder for those who know what they're doing. (And I'm in no way claiming to be a competent developer, this is just an opinion :]) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Le 17/04/2012 22:44, Brendan Eich a écrit : Brendan Eich wrote: Irakli Gozalishvili wrote: It would be amazing to have clojure like protocols in JS even without `IFn`. I think it's very good feet and very useful in JS where each library has it's own flavored API. I wrote more about it here: http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post Still hoping Mark will weigh in. Ok, I talked to Mark and Tom Van Cutsem, and they see no problem provided we prevent overriding built-in [[Call]] and [[Construct]] on function objects. Let there be private names @call and @construct (I'll spell them this way to avoid tedious imports of const bindings from @std or another built-in module). (...) This also simplifies direct proxies by allowing any proxy to have call and construct traps. Speaking of proxies and private names, how would the 2 private name interact with the proxies? It seems that it would be poorly because of the private-names-can-be-revealed-as-property-names-in-traps rule. Is it time to consider unique names? Since @call and @construct would be available to anyone, they are not much that private anyway. Change 11.4.3 The typeof Operator, the table row with Object (native or host and does implement [[Call]]) in column 1, to test not for [[Call]] and *not* for @call, rather to test [[NativeBrand]] === Function (see ES6 draft 15.2.4.2 Object.prototype.toString ( )). This last point is important: we do not want an object's typeof-type to change by giving it a @call property. This was a strong concern and the solution is satisfying as far as I'm concerned. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: try without catch or finally
Why is the argument and curly brace syntax required for except? Why
not simply allow:
try {
throw ExceptionalException;
} catch dosubroutine();
which for the convenience of Jussi's original ask:
try {
//fail
} catch null;
(or if you prefer, a noop call). The lack of parentheses make it clear
that the word following 'except' is not the error parameter, and the
lack of braces clearly means the catch-phrase ends at the semicolon.
It could even be immediately followed by a finally, which I think
yields some terse, but useful syntax that's intuitive and consistent.
try foo();
catch bar();
finally cleanUp();
in the same spirit as
if (foo) doFoo();
else doBar();
-Michael A. Smith
On Wed, Apr 18, 2012 at 5:45 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Silent catch-alls like that are almost always bad code. I think the
language rather shouldn't encourage this pattern with extra
convenience.
I don't see how this would be much more encouraging than allowing for the
catch block to do nothing. The people who would use this would leave the
catch block empty anyway.
I am also perplexed as to how often things are countered with similar
arguments. Incompetent programmers make bad decisions regardless of how much
the language/framework/library does to prevent this. In my mind it's not a
valid excuse for not making things harder for those who know what they're
doing. (And I'm in no way claiming to be a competent developer, this is just
an opinion :])
/Andreas
___
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
Shepherd.js - Implementing Harmony modules for today's browsers
Hi, I wanted to announce that I've been working on a project called Shepherd ( http://xcambar.github.com/shepherd-js), a pure Javascript implementation of Harmony modules. Why such a project ? Fun first. Second, I was really looking forward to use harmony modules. Third, I wanted an efficient way to use my modules on the server and the client. And it seems to me that current module loaders and APIs available will be, at the end, superseded by the module syntax being defined at ECMA for the future versions of ECMAScript. The syntax used is as of 2012-02-27 ( http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1330363672), I couldn't find the time to implement the latest proposal (besides I would have had to choose one of the two variants), but apart from the syntax, it is usable both on the client and the server, and tested. The parser/lexer has been developped using JISON ( http://zaach.github.com/jison/) and is available as a separate project ( https://github.com/xcambar/harmony-parser). For backward-compatibility, the module declarations have to be put into comments (which you will discover in the examples provided on the site), it is compatible with CommonJS modules (user-defined as well as native modules in Node.js), and, although not critical to the project, a compatibility wrapper for the AMD API is on its way. Regarding production-level requirements, an optimizer has been implemented, but it still requires testing before being released. I've had and I'm still having a really good time working on this project and I would really appreciate if I could have some feedback from the readers and contributors of the mailing-list. A mailing list has been created for the project, still empty of messages simply because it has been created yesterday ;) Regards, -- Xavier CAMBAR @xcambar https://twitter.com/#!/xcambar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
This is great! I've been considering doing the same thing, but I haven't found the time. When you say it is compatible with CommonJS modules, does that mean that you can do an import using ES6 syntax and have the result do a CommonJS require? The big thing I'm noticing is that all of the examples are inside of comments, and your module definitions including exports are all separate from the actual code for those exports. I'm assuming that means somebody couldn't actually take the ES6 module examples and make them work, for example. I appreciate the difference in difficulty level. Parsing just the module syntax vs being an ES5 compliant parser + modules is a much different task. The problem is, I don't see myself using it unless it actually used full module syntax. Do you plan on going in that direction? - Russ On Wed, Apr 18, 2012 at 8:20 AM, Xavier CAMBAR xcam...@gmail.com wrote: Hi, I wanted to announce that I've been working on a project called Shepherd ( http://xcambar.github.com/shepherd-js), a pure Javascript implementation of Harmony modules. Why such a project ? Fun first. Second, I was really looking forward to use harmony modules. Third, I wanted an efficient way to use my modules on the server and the client. And it seems to me that current module loaders and APIs available will be, at the end, superseded by the module syntax being defined at ECMA for the future versions of ECMAScript. The syntax used is as of 2012-02-27 ( http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1330363672), I couldn't find the time to implement the latest proposal (besides I would have had to choose one of the two variants), but apart from the syntax, it is usable both on the client and the server, and tested. The parser/lexer has been developped using JISON ( http://zaach.github.com/jison/) and is available as a separate project ( https://github.com/xcambar/harmony-parser). For backward-compatibility, the module declarations have to be put into comments (which you will discover in the examples provided on the site), it is compatible with CommonJS modules (user-defined as well as native modules in Node.js), and, although not critical to the project, a compatibility wrapper for the AMD API is on its way. Regarding production-level requirements, an optimizer has been implemented, but it still requires testing before being released. I've had and I'm still having a really good time working on this project and I would really appreciate if I could have some feedback from the readers and contributors of the mailing-list. A mailing list has been created for the project, still empty of messages simply because it has been created yesterday ;) Regards, -- Xavier CAMBAR @xcambar https://twitter.com/#!/xcambar ___ 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: Shepherd.js - Implementing Harmony modules for today's browsers
Thanks for your comments, I'm glad you liked it.
About CommonJS, the compatibility is the other way round. Shepherd can load
commonJS modules without the addition of the in-comment syntax declaration.
In such a case, require is wrapped to load whether an already loaded ES6
module or use commonJS's require. furthermore, exports or module.exports is
used as the public API of the ES6 module (which is basically the definition
:) ). This is really useful for 3rd party modules.
Removing the comments would be possible, but it would require a much
heavier parsing phase, and would probably require a full-blown JS parser,
such as Esprima. it would be probably computationnally too heavy for the
browser (read: for the user) without a systematic and automatic
code-rewrite to ES5, optionnaly accompagned with some minification.
On the other hand, the great advantage of using comments is that they act
as placeholders for the syntax declaration, and are very easy to locate
with a single regular expression.
More realistically, I plan on allowing multiple module declarations in a
single file (currently one only), where module implementations would be
syntactically separated by the numerous definitions (ie, the implementation
of a module ends at the beginning of the next module declaration).
But yes, I am looking for an efficient way to remove the comments, which
would be the only way Shepherd could be used as an efficient
Harmony:modules polyfill. Maybe I'll have to play around with more
minimalist placeholders, such as:
//s6d
module myModule {
import x from X;
export a, b, c, d;
}
//-s6d
...though the ending comment doesn't seem necessary.
And please don't blame me for the possible terrible idea, I'm thinking
aloud on this one! ;)
The tradeoff to be found is the following: As of today, no browser has a
stable release that allows harmony modules (yeah, the latest V8 has an
option, well...). Whatsmore, the syntax is just a proposal which is updated
almost every quarter. So do we want to allow files that work on today's
engines and can be enhanced with Harmony:modules' features thankd to
Shepherd, or do we want Harmony compliant files that won't run natively on
any stable engine we can find today?
I chose the first path, but the discussion remains open. I'll be happy to
hear your thoughts on that point.
Xavier
On Wed, Apr 18, 2012 at 3:11 PM, Russell Leggett
russell.legg...@gmail.comwrote:
This is great! I've been considering doing the same thing, but I haven't
found the time. When you say it is compatible with CommonJS modules, does
that mean that you can do an import using ES6 syntax and have the result do
a CommonJS require?
The big thing I'm noticing is that all of the examples are inside of
comments, and your module definitions including exports are all separate
from the actual code for those exports. I'm assuming that means somebody
couldn't actually take the ES6 module examples and make them work, for
example. I appreciate the difference in difficulty level. Parsing just the
module syntax vs being an ES5 compliant parser + modules is a much
different task. The problem is, I don't see myself using it unless it
actually used full module syntax. Do you plan on going in that direction?
- Russ
On Wed, Apr 18, 2012 at 8:20 AM, Xavier CAMBAR xcam...@gmail.com wrote:
Hi,
I wanted to announce that I've been working on a project called Shepherd (
http://xcambar.github.com/shepherd-js), a pure Javascript implementation
of Harmony modules.
Why such a project ? Fun first. Second, I was really looking forward to
use harmony modules. Third, I wanted an efficient way to use my modules on
the server and the client. And it seems to me that current module loaders
and APIs available will be, at the end, superseded by the module syntax
being defined at ECMA for the future versions of ECMAScript.
The syntax used is as of 2012-02-27 (
http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1330363672),
I couldn't find the time to implement the latest proposal (besides I would
have had to choose one of the two variants), but apart from the syntax, it
is usable both on the client and the server, and tested.
The parser/lexer has been developped using JISON (
http://zaach.github.com/jison/) and is available as a separate project (
https://github.com/xcambar/harmony-parser).
For backward-compatibility, the module declarations have to be put into
comments (which you will discover in the examples provided on the site), it
is compatible with CommonJS modules (user-defined as well as native modules
in Node.js), and, although not critical to the project, a compatibility
wrapper for the AMD API is on its way.
Regarding production-level requirements, an optimizer has been
implemented, but it still requires testing before being released.
I've had and I'm still having a really good time working on this project
and I would really appreciate if I could have some feedback from the
readers and
Re: callable objects ?
The original post in this thread, from David Nolen, cited https://gist.github.com/2346460 In general there are more callable objects under the sun than function objects, but if the only way to make one is to write a proxy (now a direct proxy), the tax is too high: * Two object allocations not one. * A priori set-up when you might need mutation of an existing object to become callable. These may not motivate you, I'm not trying to sell anyone. We should discuss utility and trade-offs more, so thanks for posting. David mentioned Dart's considering a callable protocol too. I found this: http://groups.google.com/a/dartlang.org/group/misc/browse_frm/thread/6b4f18132adfaa78/c2cfd0daadba67f1?lnk=gstq=callable#c2cfd0daadba67f1 but I'm not sure if it is the latest. Perhaps you know more? /be Andreas Rossberg wrote: I'm sorry, but can somebody explain what the real use case for all this would be? And why proxies do not already cover it? Do we really need to make _every_ object into half a (mutable?) function proxy now? /Andreas ___ 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
destructuring: as patterns?
Looking through the destructuring proposal
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
there seems to be no mention of 'as' patterns. In typical pattern
matching constructs (SML, Haskell, ..), 'as' patterns allow to name
a sub-object while continuing the match for its sub-structures.
For instance, with
var obj = { a: 0, b: { x: 1, y: 2} };
something like
let { b: b as {x,y} } = obj
would result in the bindings of b to obj.b, x to obj.b.x, y to obj.b.y.
This avoids needless repetition when both a subobject and its
components need to be extracted. Without 'as', each such case
leads to a separate destructuring assignment
let { b } = obj
let { b: {x,y} } = obj
Shouldn't 'as' patterns be included in destructuring? Or have I
missed an equivalent feature?
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Le 17/04/2012 22:44, Brendan Eich a écrit : Let there be private names @call and @construct (I'll spell them this way to avoid tedious imports of const bindings from @std or another built-in module). Let Clause 15.3.5 include new non-configurable, non-writable properties of function objects named by @call and @construct (built-in functions have only @call). The values are built-in and need a bit more thought than I can spare now, but see below: @call's value is close to the original value of Function.prototype.call, and @construct's value is straightforward enough I think. (...) Change 11.2.3 Function Calls to use @call not [[Call]], passing the /thisValue/ and /argList/ according to the Function.prototype.call convention: (thisValue, ...argList). @call as own property only or is it inherited as well? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
David Bruant wrote: Change 11.2.3 Function Calls to use @call not [[Call]], passing the /thisValue/ and /argList/ according to the Function.prototype.call convention: (thisValue, ...argList). @call as own property only or is it inherited as well? I see no reason to require own. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
/be
Claus Reinke wrote:
Looking through the destructuring proposal
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
there seems to be no mention of 'as' patterns. In typical pattern
matching constructs (SML, Haskell, ..), 'as' patterns allow to name a
sub-object while continuing the match for its sub-structures.
For instance, with
var obj = { a: 0, b: { x: 1, y: 2} };
something like
let { b: b as {x,y} } = obj
would result in the bindings of b to obj.b, x to obj.b.x, y to obj.b.y.
This avoids needless repetition when both a subobject and its
components need to be extracted. Without 'as', each such case
leads to a separate destructuring assignment
let { b } = obj
let { b: {x,y} } = obj
Shouldn't 'as' patterns be included in destructuring? Or have I
missed an equivalent feature?
Claus
___
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: destructuring: as patterns?
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 it? Certainly not the general JS development
community.
let {b} = obj;
let {x,y} = b;
but of course one would just write
let {x, y} = obj.b;
in that contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
/be
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.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 declarations without much repetition:
But who has been using it? Certainly not the general JS development
community.
let {b} = obj;
let {x,y} = b;
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
but of course one would just write
let {x, y} = obj.b;
in that contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
/be
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.
David
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 grammar and parsing algorithm
(LR(1) with lookahead and [no LineTerminator here] restrictions). In
binding forms we can specialize the pattern sub-grammar and IIRC Allen's
draft ES6 spec does.
In contrast, for general destructuring assignment expressions, the LHS
must be covered by ObjectLiteral or ArrayLiteral. No 'as' in those, but
perhaps this just says that 'as', if we add it, is only in the binding
forms' pattern sub-grammar.
/be
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 declarations without much repetition:
But who has been using it? Certainly not the general JS development
community.
let {b} = obj;
let {x,y} = b;
but of course one would just write
let {x, y} = obj.b;
in that contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
/be
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.
David
___
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: destructuring: as patterns?
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 property names in destructuring patterns. Claus's 'as' syntax
avoids that problem and could even be shortened:
let { b as {x,y} } = obj
to bind b, x, and y, instead of what was in the o.p.:
let { b: b as {x,y} } = obj
DRY and EIBTI argue for 'as' and the shorter shorthand.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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
basic building blocks that are currently missing. They are extremely
useful in practice, for a very small price -- i.e., they are trivial
to spec and implement, (unlike callable objects, because Brendan just
mentioned those :) ).
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 of course one would just write
let {x, y} = obj.b;
in that contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
To be honest I've being running into cases where I wished I could match both
parent and children in some way. Also, I think that Herby's version is better
in fact I had to learn that it's illegal. Unless it's too much of a deal I'd
also like following to work:
let { a, b, b: { x, y } } = object;
/be
Claus Reinke wrote:
Looking through the destructuring proposal
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
there seems to be no mention of 'as' patterns. In typical pattern
matching constructs (SML, Haskell, ..), 'as' patterns allow to name a
sub-object while continuing the match for its sub-structures.
For instance, with
var obj = { a: 0, b: { x: 1, y: 2} };
something like
let { b: b as {x,y} } = obj
would result in the bindings of b to obj.b, x to obj.b.x, y to obj.b.y.
This avoids needless repetition when both a subobject and its
components need to be extracted. Without 'as', each such case
leads to a separate destructuring assignment
let { b } = obj
let { b: {x,y} } = obj
Shouldn't 'as' patterns be included in destructuring? Or have I
missed an equivalent feature?
Claus
___
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 (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: destructuring: as patterns?
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, albeit in different form?
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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, 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 of course one would just write
let {x, y} = obj.b;
in that contrived case.
Main thing is, not having as-patterns is not a big deal based on
experience with JS1.7+ since 2006 in Mozilla code.
To be honest I've being running into cases where I wished I could match both
parent and children in some way. Also, I think that Herby's version is
better in fact I had to learn that it's illegal. Unless it's too much of a
deal I'd also like following to work:
let { a, b, b: { x, y } } = object;
/be
Claus Reinke wrote:
Looking through the destructuring proposal
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
there seems to be no mention of 'as' patterns. In typical pattern
matching constructs (SML, Haskell, ..), 'as' patterns allow to name a
sub-object while continuing the match for its sub-structures.
For instance, with
var obj = { a: 0, b: { x: 1, y: 2} };
something like
let { b: b as {x,y} } = obj
would result in the bindings of b to obj.b, x to obj.b.x, y to obj.b.y.
This avoids needless repetition when both a subobject and its
components need to be extracted. Without 'as', each such case
leads to a separate destructuring assignment
let { b } = obj
let { b: {x,y} } = obj
Shouldn't 'as' patterns be included in destructuring? Or have I
missed an equivalent feature?
Claus
___
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 (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: destructuring: as patterns?
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 must be added for it.
I'd say use '=' as in assignment:
let {b:b={x,y}} = obj;
let [a,b={x,y},c] = arr;
I agree that 'as' patterns (and even more so, wildcard patterns) are
basic building blocks that are currently missing. They are extremely
useful in practice, for a very small price -- i.e., they are trivial
to spec and implement, (unlike callable objects, because Brendan just
mentioned those :) ).
/Andreas
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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
FF11 firebug console; just tried), so why include as if it already is
there, albeit in different form?
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
Herby
___
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: destructuring: as patterns?
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 arrays, for example.
Yeah. :-/
Argument lists are the more interesting case, btw. Layering has to be
an independent and compositional construct.
Then either not have it or syntax must be added for it.
I'd say use '=' as in assignment:
let {b:b={x,y}} = obj;
let [a,b={x,y},c] = arr;
Unfortunately, that's already taken for default values, 'as' probably
is as good as you can get.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 already
is there, albeit in different form?
We implemented destructuring years ago to implementor- and user-test ES4
proposals. They did not forbid duplicates. That's all.
Nothing normative in experimental Firefox implementation features, of
course. You cite them as already [there] and that's true but it
doesn't govern what goes into ES6.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 duplicate property names in object literals, so
this might well apply to duplicate property names in object patterns. I
still think this may be the case.
ES4-era destructuring was very shallow sugar:
var {x: y} = z; = var y = z.x;
and so on -- with a temporary to avoid evaluating z more than once, and
z is evaluated first (a left-to-right evaluation order break, but others
exist, e.g. for-in loop head evaluation order).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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
firebug console; just tried), so why include as if it already is there,
albeit in different form?
We implemented destructuring years ago to implementor- and user-test ES4
proposals. They did not forbid duplicates. That's all.
Nothing normative in experimental Firefox implementation features, of course.
You cite them as already [there] and that's true but it doesn't govern what
goes into ES6.
But is also works this way according to the ES6 draft spec. It works with var
because var allows duplicated declarations:
var a=1;
var a=2;
var a=3;
which, from a declaration perspective isn't really any different from
var a=1,a=2,a=3;
However let/const does not:
{ //block level duplicate declaration early error
let b=1;
let b=2;
}
or just
let b=1,b=2 ; //block level duplicate declaration error
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 that the second b in the destructuring isn't actually
introducing a binding for b. However, syntactically it looks like one and
that is what the static semantic rule is driven off of. If we allow that, we
would also be allowing:
let b=somethingElse;
let {b:{x,y})=obj;
If we want to allow that I'll have to some up with a different way to specify
the static semantics.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Legacy const
const is needed in non-strict/strict code, as well as in Harmony code, has historically been needed for web compatibility on non-IE code. Chakra interestingly doesn't support it. (May simply be a case of it being IE and not fed code that realizes upon it.) Either we should spec it, likely block-scoped in modules as it is now and function-scoped otherwise, or everyone should drop it. (I doubt that's feasible, though.) -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 SML and variants, 'pat=pat' in Erlang,
'as pat var' in (little-known) KiR).
Those constructs are hard to search for on github (too many
false matches, though searching for 'as' in Standard ML code
might work), but I find them both useful and popular.
Some of the usefulness comes from using pattern matching
as a structural guard (checking the substructure conforms to
a pattern, then just naming the substructure wholesale). I
have no experience with a language that only destructures,
without matching, but I would expect to use as-patterns
with destructuring as well, increasingly so with upcoming
language constructs.
The main problems seem to be cover-grammars (construct
should be valid expression and pattern), and that the obvious
choice '=' is already taken for default parameters.
A common generalization of as-patterns are conjunctive
patterns (as in Successor ML or Erlang), which suggests
'patpat' or perhaps '(pat,pat)' as alternative syntax.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 from a negative result that's clear (no confounders). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Le 18/04/2012 17:14, Brendan Eich a écrit :
David Bruant wrote:
Change 11.2.3 Function Calls to use @call not [[Call]], passing
the /thisValue/ and /argList/ according to the
Function.prototype.call convention: (thisValue, ...argList).
@call as own property only or is it inherited as well?
I see no reason to require own.
After giving some more thoughts:
function f(){
return 12;
}
var o = Object.create(f);
o();
Currently this throws a TypeError (o isn't a function). If the @call
property was inherited, the inherited @call would be called (and no
error would be thrown).
I don't know to what extent it matters, but it's worth noting there
would be this difference.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const
Const is spec'ed in the ES6 draft for all modes (there is really only strict and non-strict, no longer a Harmony mode). It is block scoped. If anybody wants to update their current implementation ahead of ES6 that's that they should for the ES6 draft spec.. Note that current interoperable uses of const (in browsers that support it) is probably limited to global code or the top level of functions (ie, not within blocks) so correctly supporting block level const probably won't break anything. Allen On Apr 18, 2012, at 9:54 AM, Geoffrey Sneddon wrote: const is needed in non-strict/strict code, as well as in Harmony code, has historically been needed for web compatibility on non-IE code. Chakra interestingly doesn't support it. (May simply be a case of it being IE and not fed code that realizes upon it.) Either we should spec it, likely block-scoped in modules as it is now and function-scoped otherwise, or everyone should drop it. (I doubt that's feasible, though.) -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ 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: callable objects ?
Yes, I thought of that -- currently o() throws, so in the best case,
there's no impediment to relaxing things to allow o() to call. In the
worst case, code that caught or counted on the exception somehow might
break.
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
Are some of these proposed and novel base-level traps better off
own-only, in spite of this general rule?
/be
David Bruant wrote:
Le 18/04/2012 17:14, Brendan Eich a écrit :
David Bruant wrote:
Change 11.2.3 Function Calls to use @call not [[Call]], passing
the /thisValue/ and /argList/ according to the
Function.prototype.call convention: (thisValue, ...argList).
@call as own property only or is it inherited as well?
I see no reason to require own.
After giving some more thoughts:
function f(){
return 12;
}
var o = Object.create(f);
o();
Currently this throws a TypeError (o isn't a function). If the @call
property was inherited, the inherited @call would be called (and no
error would be thrown).
I don't know to what extent it matters, but it's worth noting there
would be this difference.
David
___
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: destructuring: as patterns?
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 of the box (in FF11
firebug console; just tried), so why include as if it already is there, albeit
in different form?
We implemented destructuring years ago to implementor- and user-test ES4
proposals. They did not forbid duplicates. That's all.
Nothing normative in experimental Firefox implementation features, of course. You cite
them as already [there] and that's true but it doesn't govern what goes into
ES6.
But is also works this way according to the ES6 draft spec. It works with var
because var allows duplicated declarations:
var a=1;
var a=2;
var a=3;
which, from a declaration perspective isn't really any different from
var a=1,a=2,a=3;
However let/const does not:
{ //block level duplicate declaration early error
let b=1;
let b=2;
}
or just
let b=1,b=2 ; //block level duplicate declaration error
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
}
But the 'let {b:b, b:{x,y}}' is different beast, it is:
{
let b = {x:1,y:2};
let {x,y} = {x:1,y:2};
}
and there is, imo, no conflict in this.
You might argue that the second b in the destructuring isn't actually
introducing a binding for b. However, syntactically it looks like
one and that is what the static semantic rule is driven off of. If
we allow that, we would also be allowing:
let b=somethingElse;
let {b:{x,y})=obj;
If we want to allow that I'll have to some up with a different way to
But, AFAICT, this should be allowed. The 'b:' from destructuring is
different from 'b' from let. Is the previous code disallowed in current
state?
specify the static semantics.
Allen
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Legacy const, attempt 2 (Re: Legacy const)
I've just had it pointed out to me that my original email made little sense, so let's try again: const has historically been needed in non-strict/strict code for web compatibility on non-IE code (typically either down to server-side UA sniffing or just explicitly non-support of IE). IE still doesn't support it, which may suggest it's not needed for compatibility any more, but as far as I can tell removing it would break enough to make it infeasible. As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. -- Geoffrey Sneddon — Opera Software http://gsnedders.com http://opera.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 that the second b in the destructuring isn't actually
introducing a binding for b. However, syntactically it looks like one and
that is what the static semantic rule is driven off of. If we allow that, we
would also be allowing:
let b=somethingElse;
let {b:{x,y})=obj;
If we want to allow that I'll have to some up with a different way to specify
the static semantics.
False alarm! Actually the above isn't correct. The current spec draft actually
does allow
let {b,b:{x,y}};
but would issue an early error on
let {b,b:{x:b,y}};
It is all in the static semantics production Bound Names in 12.2.4
The BoundNames of
let {b}=obj
is [b]
The BoundNames of
let {b:x} = obj
is [x]
The Bound Names of
let {b,b:{x,y}
is [b,x,y]
The Bound Names of
let {b,b:{x:b,y}};
is [b,b,y] and produces a duplicate declaration early error. For a var
declaration it would be allowd.
Sorry for the confusion. I should have read my own spec. more carefully.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
Geoffrey Sneddon wrote: As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. The TC39 group met early this year (IIRC it was the Yahoo!-hosted meeting in January) and Gavin B. of Apple agreed to try changing const to match ES6 (block-scoped everywhere), and to reserve 'let' everywhere too. TC39 is not inclined to maximize compatibility for 'const' given non-support in IE so far, and enough non-interoperation among the other browser implementations to keep web developers from relying on it even in non-IE (if (!document.all)) code forks. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 proposed at one point, IIRC, but a while ago.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Legacy const, attempt 2 (Re: Legacy const)
On Apr 18, 2012, at 11:32 AM, Brendan Eich bren...@mozilla.org wrote: Geoffrey Sneddon wrote: As such, we should spec it: likely block-scoped in modules, and function-scoped otherwise. We should only really not spec it if we can get everyone who currently supports it to drop it. The TC39 group met early this year (IIRC it was the Yahoo!-hosted meeting in January) and Gavin B. of Apple agreed to try changing const to match ES6 (block-scoped everywhere), and to reserve 'let' everywhere too. Alas reserving let everywhere failed, at least one canadian bank has some (really screwed up) code that has a variable named let. Gavin and I are pondering the difficulty of having let reserved everywhere unless you use it in a non-let syntax. TC39 is not inclined to maximize compatibility for 'const' given non-support in IE so far, and enough non-interoperation among the other browser implementations to keep web developers from relying on it even in non-IE (if (!document.all)) code forks. /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: destructuring: as patterns?
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 assignments in array
literals:
let [b, 0:{x,y}];
This was proposed at one point, IIRC, but a while ago.
It was also suggested that we allow iterators/generators to supply the
initialization values to array destructurings. This currently isn't in the
draft spec. and I think it would introduce some fairly significant
specification and practical complications (eg, rest bindings and open-ended
generators).
However, the reason I bring it up it that if we ever do want to add that sort
of generative initialization value feature, it would seem to have significant
interactions with the explicit array property designator feature shown above.
The most future proof thing for right now would be to do neither.
Allen
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 suggested that we allow iterators/generators to supply the
initialization values to array destructurings. This currently isn't in the
draft spec. and I think it would introduce some fairly significant
specification and practical complications (eg, rest bindings and open-ended
generators).
Destructuring patterns should be static. I don't see a conflict if we
stick to this rule, but given the ability to use an object pattern, I
don't see a need for the array literal element label syntax either.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 also suggested that we allow iterators/generators to supply the
initialization values to array destructurings. This currently isn't in
the draft spec. and I think it would introduce some fairly significant
specification and practical complications (eg, rest bindings and
open-ended generators).
Destructuring patterns should be static. I don't see a conflict if we
stick to this rule, but given the ability to use an object pattern, I
don't see a need for the array literal element label syntax either.
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 object.
(but if it is not the problem, I'd gladly see at least the object
double-destructure-same-field in ES6. It is not violating the no double
property names of strict mode since the assignment goes the other way)
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 object.
Why can't you use an object pattern? Array pattern is just shorthand for
object pattern.
(but if it is not the problem, I'd gladly see at least the object
double-destructure-same-field in ES6. It is not violating the no
double property names of strict mode since the assignment goes the
other way)
Yes, Allen covered this five messages back in the thread. There's no
problem because the set of bindings has no dups. Destructuring as dual
of object or array literals threw me (even me, a big fan of duality --
but only briefly ;-).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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, you
cannot opt for object.
Why can't you use an object pattern? Array pattern is just shorthand for
object pattern.
Not implicitly, not inside the argument list itself.
You would need to write
function foo (...args) {
let {0:b, 0:{x,y}, foo, bar, baz} = args;
...
}
but between 'foo (' and ') {' you must play by the rules of array
destructuring, where '0:' is not allowed.
/be
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 destructure like so:
let {0: b, 0: {x, y}} = ...;
It was also suggested that we allow iterators/generators to supply the
initialization values to array destructurings. This currently isn't in
the draft spec. and I think it would introduce some fairly significant
specification and practical complications (eg, rest bindings and
open-ended generators).
Destructuring patterns should be static. I don't see a conflict if we
stick to this rule, but given the ability to use an object pattern, I
don't see a need for the array literal element label syntax either.
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 object.
function f({b},...rest) {
let {x,y}=b;
...
}
doesn't seem like too much of a burden
(but if it is not the problem, I'd gladly see at least the object
double-destructure-same-field in ES6. It is not violating the no double
property names of strict mode since the assignment goes the other way)
It's in the spec. draft. There aren't actually object literals so the
duplicate property name rules don't apply. It's the duplicate lexical binding
rules that are in play, but only on the target names, not the property
selectors.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 way to do it is:
function foo ({b}, ...args) {
let {x,y} = b;
let [foo, bar, baz] = args;
...
}
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
Hi Xavier, It's great to see this project! I'll take a closer look soon. I will see if I can help contribute to this. Dave On Apr 18, 2012, at 5:20 AM, Xavier CAMBAR wrote: Hi, I wanted to announce that I've been working on a project called Shepherd (http://xcambar.github.com/shepherd-js), a pure Javascript implementation of Harmony modules. Why such a project ? Fun first. Second, I was really looking forward to use harmony modules. Third, I wanted an efficient way to use my modules on the server and the client. And it seems to me that current module loaders and APIs available will be, at the end, superseded by the module syntax being defined at ECMA for the future versions of ECMAScript. The syntax used is as of 2012-02-27 (http://wiki.ecmascript.org/doku.php?id=harmony:modulesrev=1330363672), I couldn't find the time to implement the latest proposal (besides I would have had to choose one of the two variants), but apart from the syntax, it is usable both on the client and the server, and tested. The parser/lexer has been developped using JISON (http://zaach.github.com/jison/) and is available as a separate project (https://github.com/xcambar/harmony-parser). For backward-compatibility, the module declarations have to be put into comments (which you will discover in the examples provided on the site), it is compatible with CommonJS modules (user-defined as well as native modules in Node.js), and, although not critical to the project, a compatibility wrapper for the AMD API is on its way. Regarding production-level requirements, an optimizer has been implemented, but it still requires testing before being released. I've had and I'm still having a really good time working on this project and I would really appreciate if I could have some feedback from the readers and contributors of the mailing-list. A mailing list has been created for the project, still empty of messages simply because it has been created yesterday ;) Regards, -- Xavier CAMBAR @xcambar ___ 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: callable objects ?
Le 18/04/2012 19:48, Brendan Eich a écrit :
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
I agree with your point.
However, I'd like to restate that interaction between proxies and
private names as currently design is unusable:
var callName = import @call;
var target = {
[callName]: function(){console.log('yo')}
};
var p = Proxy(target, {});
p(); // throws exception because the proxy is reported as not having
a @call property
In the get trap of the proxy, the @call private name is transformed into
its public conterpart. When, by default, the trap forwards to the
target, the public alter-ego is coerced into a string. Consequently, the
actual @call property of the target isn't found.
Are some of these proposed and novel base-level traps better off
own-only, in spite of this general rule?
Did you mean traps or private properties? Assuming private properties.
The precedent here is the different non-standard pseudo-properties.
For __noSuchMethod__, it is inherited which is probably what is
expected. I tested with:
===
var o = {};
o.__noSuchMethod__ = function(n){
console.log('__noSuchMethod__ call', n);
}
o.a();
var o2 = Object.create(o);
o2.c()
===
__defineGetter__ and __defineSetter__ only made sense as if considered
as own properties I think.
__proto__ would make sense as an own property reflecting directly
objects own internal [[Prototype]] property (which seems to be V8
behavior). Reality and security concerns make it a different story
Besides specific cases of things that touch the specific aspects of
singular object, I agree that inheriting is better.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shepherd.js - Implementing Harmony modules for today's browsers
This is quite interesting. I really feel that the comment syntax is pretty ugly. Parsing JS is non trivial but it is not a performance issue. If you expect this to have some uptake I would expect it to use the real module syntax and not rely on comments. By coincidence I landed import support to Traceur last night. You might want want to check it out. It also doesn't use the latest syntax since the current BNF on the wiki is incomplete. http://code.google.com/p/traceur-compiler/source/browse/#git%2Ftest%2Ffeature%2FModules http://code.google.com/p/traceur-compiler/source/detail?r=f4f8788860f624ca1b02883890325cbb4ee9c1eb Traceur does have a CodeLoader that allows loading external js files but it is not very convenient to use at this point. We have an open bug to allow offline compilation of modules with external dependancies. http://code.google.com/p/traceur-compiler/issues/detail?id=87 -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 ban (repeated
property names in literals).
The repeated property-name thing is a hack. It does not Say What You Mean (it's
a total surprise). It is not composable (it only works for property names, not
for array indices).
Worst of all, it will trigger getters twice:
let { b, b: { x, y } } = { get b() { console.log(BOO!); return 17 } }
BOO!
BOO!
But if that's the only way to do it, then if you want to destructure a getter,
you will be forced not to use the hack, and to bind a temporary variable and do
a second destructuring on a second line.
*Please*, let's do this right. There's no reason to introduce hacks. I'm open
to various syntaxes, but I think `as` is nice especially because it could work
well for import/export syntax too. Lots of people complain about confusion over
which is the bound name and which is the label. IINM, we could allow both:
let { x: x as y } = obj;
and
let { x as y } = obj;
which would be a nice idiom for making it more obvious that x is the label and
y is the binding. Then this would be especially nice for imports:
import { x as y } from X;
Dave
On Apr 18, 2012, at 8:57 AM, Andreas Rossberg wrote:
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
basic building blocks that are currently missing. They are extremely
useful in practice, for a very small price -- i.e., they are trivial
to spec and implement, (unlike callable objects, because Brendan just
mentioned those :) ).
/Andreas
___
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: destructuring: as patterns?
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 effects,
and does not violate restrictions that IINM strict mode is supposed to ban
(repeated property names in literals).
The repeated property-name thing is a hack. It does not Say What You Mean
(it's a total surprise). It is not composable (it only works for property
names, not for array indices).
Worst of all, it will trigger getters twice:
let { b, b: { x, y } } = { get b() { console.log(BOO!); return 17 }
}
BOO!
BOO!
But if that's the only way to do it, then if you want to destructure a
getter, you will be forced not to use the hack, and to bind a temporary
variable and do a second destructuring on a second line.
*Please*, let's do this right. There's no reason to introduce hacks. I'm
open to various syntaxes, but I think `as` is nice especially because it
could work well for import/export syntax too. Lots of people complain about
confusion over which is the bound name and which is the label. IINM, we
could allow both:
let { x: x as y } = obj;
and
let { x as y } = obj;
which would be a nice idiom for making it more obvious that x is the label
and y is the binding. Then this would be especially nice for imports:
import { x as y } from X;
Dave
+1
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: destructuring: as patterns?
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 repeated side-effects is very significant given that any property access can have arbitrary side-effects including adding and removing properties from the RHS object. Regardless, making duplicate property names an early error is easy enough and seems to eliminate a potential point of confusion. I'm not necessarily sold on as yet. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
David Bruant wrote:
Le 18/04/2012 19:48, Brendan Eich a écrit :
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
I agree with your point.
However, I'd like to restate that interaction between proxies and
private names as currently design is unusable:
var callName = import @call;
var target = {
[callName]: function(){console.log('yo')}
};
Just as an aside, and to avoid confusion (import doesn't work that way),
let's say it is:
var target = {
@call: function(){console.log('yo')}
};
var p = Proxy(target, {});
p(); // throws exception because the proxy is reported as not having
// a @call property
In the get trap of the proxy, the @call private name is transformed into
its public conterpart. When, by default, the trap forwards to the
target, the public alter-ego is coerced into a string. Consequently, the
actual @call property of the target isn't found.
Hmm, I see. The idea was to avoid leaking private names via hostile
proxies, but here we have a friendly proxy that wants to get the
private-named target property.
Tom, didn't our thinking on private names predate direct proxies? Or is
that not relevant? In the old model, the handler would need traps (some
fundamental ones at least) that special-case the public name substituted
for @call. Perhaps we need something more automagic for direct proxies
that still prevents private name leaks.
With direct proxies, if the target already has the private-named
property, and the handler ({} here) has no traps that might steal a
non-substituted private name, why would we substitute the public name
for the private @call?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Proxies seem to be able to support this well given a little bit of extra specification. A proxy attempts to forward the apply/construct action naively to its target. The result is it either succeeds or doesn't, and the same invariant checks would apply (private names have the same rules for configurability right?). The only difference is that a proxy won't know the result before actually attempting to follow through, which means that private non-configurable properties are a kind of booby trap if you *don't* always forward everything. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Errr that only applies to private properties that manifest in public results, as @construct and @call were described. In other cases the private name I would guess is simply not enforceable because there's no direct link between the private property and the outside world that has to be enforced. The shows a flaw of linking a private property with a predictable observable result. On Wed, Apr 18, 2012 at 7:26 PM, Brandon Benvie bran...@brandonbenvie.comwrote: Proxies seem to be able to support this well given a little bit of extra specification. A proxy attempts to forward the apply/construct action naively to its target. The result is it either succeeds or doesn't, and the same invariant checks would apply (private names have the same rules for configurability right?). The only difference is that a proxy won't know the result before actually attempting to follow through, which means that private non-configurable properties are a kind of booby trap if you *don't* always forward everything. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
The issue you may be missing (sorry if I'm mis-reading your post) is: hostile proxy passed into module that detects private-named properties on incoming objects. If the proxy has a handler that traps get, e.g., the private name will leak and the hostile party can now use it to decorate a trojan. So it seems to me the issue with direct proxies of whether the handler has a relevant trap for a given access matters. /be Brandon Benvie wrote: Proxies seem to be able to support this well given a little bit of extra specification. A proxy attempts to forward the apply/construct action naively to its target. The result is it either succeeds or doesn't, and the same invariant checks would apply (private names have the same rules for configurability right?). The only difference is that a proxy won't know the result before actually attempting to follow through, which means that private non-configurable properties are a kind of booby trap if you *don't* always forward everything. ___ 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: callable objects ?
On Wed, Apr 18, 2012 at 4:31 PM, Brandon Benvie bran...@brandonbenvie.com wrote: Errr that only applies to private properties that manifest in public results, as @construct and @call were described. In other cases the private name I would guess is simply not enforceable because there's no direct link between the private property and the outside world that has to be enforced. The shows a flaw of linking a private property with a predictable observable result. The private name proposal has the ability to create ordinary unique names (same basic functionality, but enumerable and passed directly to proxies), right? Obviously all the names used in the standard library should be merely unique, not private, as you're not attempting to hide anything, just prevent accidental name clashes. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
In that case I think it's worth noting that there is fundamentally different consequences between those two concepts then and requirements of one shouldn't be the same for the other. it's possible to have a private property that's non-configurable which has no bearing on proxies while that's obviously not true of anything public. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: callable objects ?
Good point, but http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects still has that visibility flag as an open issue. We need to settle this, sooner is better ;-). /be Tab Atkins Jr. wrote: On Wed, Apr 18, 2012 at 4:31 PM, Brandon Benvie bran...@brandonbenvie.com wrote: Errr that only applies to private properties that manifest in public results, as @construct and @call were described. In other cases the private name I would guess is simply not enforceable because there's no direct link between the private property and the outside world that has to be enforced. The shows a flaw of linking a private property with a predictable observable result. The private name proposal has the ability to create ordinary unique names (same basic functionality, but enumerable and passed directly to proxies), right? Obviously all the names used in the standard library should be merely unique, not private, as you're not attempting to hide anything, just prevent accidental name clashes. ~TJ ___ 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: callable objects ?
This has been a useful thought experiment then. Private properties which are defined as directly linked to observable results seem to be a bad idea because that means a proxy is required to either always forward anything that can invoke that observable public/private relationship or the other option is unenforced invariants. If you keep the link between a private property and directly linked observable results opaque then you can allow proxies to completely ignore any invariant about them because there is no actual invariant to enforce. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
