(or you simply don't trap the access, which is the route for [[prototype]],
[[instanceof]], etc which now makes even more sense to me in light of this)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 opti
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
wrote:
Errr that only applies to p
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 obviou
On Wed, Apr 18, 2012 at 4:31 PM, Brandon Benvie
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 pr
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
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.
Th
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
configu
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
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 a
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@mozill
On Wed, Apr 18, 2012 at 5:35 PM, David Herman 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
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 ba
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
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
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-j
Allen Wirfs-Brock wrote:
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,
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 w
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
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, yo
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 o
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 wa
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 sug
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 proper
On Apr 18, 2012, at 11:32 AM, Brendan Eich 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 me
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
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 Janua
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
_
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 a
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 d
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-dis
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
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
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
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 inherite
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 fr
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
On Wednesday, 2012-04-18 at 09:32 , Brendan Eich wrote:
> 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
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 bloc
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 o
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 duplicat
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 alre
On 18 April 2012 18:09, Herby Vojčík wrote:
> Andreas Rossberg wrote:
>>
>> On 18 April 2012 17:51, 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 won't work for arrays, fo
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 ou
Andreas Rossberg wrote:
On 18 April 2012 17:51, 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 won't work for arrays, for example.
Yeah. :-/
Then either not have it or syntax must be added for i
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,
http://www.dartlang.org/docs/spec/latest/dart-language-specification.html
If you look at the changes since 0.6 you'll see they added call for
function emulation.
On Wed, Apr 18, 2012 at 10:57 AM, Brendan Eich wrote:
> The original post in this thread, from David Nolen, cited
>
> https://gist.gi
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, albe
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;
>
On 18 April 2012 17:51, 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 won't work for arrays, for example.
I agree that 'as' patterns (and even more so, wildcard patterns) are
basic building b
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
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 g
David Nolen wrote:
On Wed, Apr 18, 2012 at 11:26 AM, Brendan Eich 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 r
On Wed, Apr 18, 2012 at 11:26 AM, 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:
>
But who has been using it? Certainly not
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
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
___
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
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-st
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 no
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
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
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
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 clea
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:
> 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
ca
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
On 17 April 2012 22:35, Jussi Kalliokoski 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 */ }
Silen
67 matches
Mail list logo
