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) { /*
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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: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
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
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
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
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
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
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
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
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 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
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
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
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:
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
63 matches
Mail list logo
