Rick Waldron wrote:
On Wednesday, May 30, 2012 at 12:09 AM, Brendan Eich wrote:
Brendan Eich wrote:
The only usable+secure extensions I see are two, so we don't confuse
users with almost-identical syntax with quite different (when it
matters most, when under attack) semantics:
A. obj.{prop:
2012/5/30 Norbert Lindenberg ecmascr...@norbertlindenberg.com:
This is for the Language Specification, not the Internationalization API
Specification.
The assumptions are in the Language Specification, so they have to be
addressed there.
A normalization API can live in the Language
On Tue, May 29, 2012 at 11:19 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Would property assignments be separated by comma or semicolon?
Eg.
o.( a = alpha, b = beta )
v.
o.( a = alpha; b = beta )
Heh, I didn't say. Comma might be just as good meaning no worse
On May 29, 2012, at 11:19 PM, Brendan Eich wrote:
o.( a = alpha, b = beta )
v.
o.( a = alpha; b = beta )
The similarity between .{ foo: bar } .{ foo= bar } concerns me, it's too
footgunish. This I like.
cheers,
G.
___
es-discuss mailing list
Le 29/05/2012 21:18, John J Barton a écrit :
On Tue, May 29, 2012 at 11:32 AM, Brendan Eichbren...@mozilla.org wrote:
John J Barton wrote:
This is one of those cases where a small delta creates a very large
negative effect.
Evidence?
If you look back on this thread you will see an example
If I correctly understood, A is for the supposedly existing case where someone
would add a property to an object before you “extend.{}” it to alter the way
that property is handled, in order to get acces to things you wouldn’t have
thought they could gain access to but that you’re putting on a
Brendan Eich wrote:
Brendan Eich wrote:
The only usable+secure extensions I see are two, so we don't confuse
users with almost-identical syntax with quite different (when it
matters most, when under attack) semantics:
A. obj.{prop: val, ...} as safe mustache, with : for define not assign.
After reading that __proto__ is becoming standardized, I was wondering what
the impacts on JSON would be. JSON is a subset of ECMAScript, so __proto__
would break current semantics. Even worse, try to run JSON.parse('{__proto__:
1}'). The result in Chrome is an empty object. It doesn't inherit
Herby Vojčík wrote:
.{...} has established ways to do things, like .{0:foo, 1:bar}
(and recently it even had .{[key]:value}).
Established how? Mustache syntax was proposed last July, it's not fully
in Harmony -- hence Allen's new strawman.
Computed property names in object literals was
Brendan Eich wrote:
You'd have to write things out the long way using obj['fo@o'), etc.
Er, obj['fo@o'] = 1; obj['ba@r'] = 2; obj['ba@z'](), I mean.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David Bruant wrote:
Additionally to JSON, I'd like to ask about if decisions have been
made for __proto__ in object literal notation.
That's part of the de-facto __proto__ standard, AFAIK.
David
Le 30/05/2012 14:07, Felix Böhm a écrit :
After reading that __proto__ is becoming
2012/5/30 Brendan Eich bren...@mozilla.com
David Bruant wrote:
Additionally to JSON, I'd like to ask about if decisions have been made
for __proto__ in object literal notation.
That's part of the de-facto __proto__ standard, AFAIK.
David
Le 30/05/2012 14:07, Felix Böhm a écrit :
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse
JSON. Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially, per ES5. What's the
problem you see?
Having __proto__ as a setter would make much more sense for me, too.
No magic
Brendan Eich wrote:
Herby Vojčík wrote:
.{...} has established ways to do things, like .{0:foo, 1:bar}
(and recently it even had .{[key]:value}).
Established how? Mustache syntax was proposed last July, it's not fully
in Harmony -- hence Allen's new strawman.
By basically saying what is
Le 30/05/2012 15:24, Brendan Eich a écrit :
David Bruant wrote:
Additionally to JSON, I'd like to ask about if decisions have been
made for __proto__ in object literal notation.
That's part of the de-facto __proto__ standard, AFAIK.
I haven't seen it discussed in the meeting notes (though it
2012/5/30 Brendan Eich bren...@mozilla.com
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse
JSON. Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially, per ES5. What's the problem
you see?
As written before, V8 ignores keys
On Wed, May 30, 2012 at 12:45 AM, David Bruant bruan...@gmail.com wrote:
Le 29/05/2012 21:18, John J Barton a écrit :
On Tue, May 29, 2012 at 11:32 AM, Brendan Eichbren...@mozilla.org
wrote:
John J Barton wrote:
This is one of those cases where a small delta creates a very large
negative
On Wed, May 30, 2012 at 7:12 AM, Felix Böhm esdisc...@feedic.com wrote:
2012/5/30 Brendan Eich bren...@mozilla.com
Felix Böhm wrote:
Okay, fair point. But JSON.parse should do what it's name says: Parse
JSON. Ignoring keys is not an option.
JSON.parse must not treat __proto__ specially,
See also http://code.google.com/p/chromium/issues/detail?id=115055
On Wed, May 30, 2012 at 10:18 AM, Mark S. Miller erig...@google.com wrote:
On Wed, May 30, 2012 at 7:12 AM, Felix Böhm esdisc...@feedic.com wrote:
2012/5/30 Brendan Eich bren...@mozilla.com
Felix Böhm wrote:
Okay, fair
On May 29, 2012, at 10:05 PM, Rick Waldron wrote:
On Wednesday, May 30, 2012 at 12:00 AM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes
I would say this is one of the places that Node shines, due to providing
very easy to use access to the C++ API of V8 directly as JS modules.
Straight copying and pasting from v8.h to a module that directly exposes
the functions to JS can provide access to most of the tools one would want
from JS
On May 30, 2012, at 6:16 AM, Brendan Eich wrote:
...
See later post suggesting obj.(foo = 1; bar = 2; baz()).
Non-Identifier property names would be a hard case, I think. You'd have to
write things out the long way using obj['fo@o'), etc.
I don't think it is very hard:
On May 29, 2012, at 23:45 , Erik Corry wrote:
2012/5/30 Norbert Lindenberg ecmascr...@norbertlindenberg.com:
This is for the Language Specification, not the Internationalization API
Specification.
The assumptions are in the Language Specification, so they have to be
addressed there.
Hello,
to make things more DRY in spec and more consistent, what if
{some_content} in expression context would be defined as syntactic sugar
for (new Object).{some_content}?
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
On May 29, 2012, at 11:59 PM, Mark S. Miller wrote:
...
I appreciate this reason ;), but I like semicolon for another reason -- the
parens suggest factoring out the o., as if
o.(stuff1; stuff2)
means the same thing as
o.stuff1; o.stuff2
where stuff1 and stuff2 are not
Below added another rule to Cascade to allow get accessor properties to be
accessed. This may not be all that important...
On May 30, 2012, at 11:02 AM, Allen Wirfs-Brock wrote:
On May 30, 2012, at 6:16 AM, Brendan Eich wrote:
...
See later post suggesting obj.(foo = 1; bar = 2;
On Wed, May 30, 2012 at 12:46 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On May 29, 2012, at 11:59 PM, Mark S. Miller wrote:
...
I appreciate this reason ;), but I like semicolon for another reason --
the parens suggest factoring out the o., as if
o.(stuff1; stuff2)
means the
On Wed, May 30, 2012 at 3:46 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On May 29, 2012, at 11:59 PM, Mark S. Miller wrote:
...
I appreciate this reason ;), but I like semicolon for another reason --
the parens suggest factoring out the o., as if
o.(stuff1; stuff2)
means the
Herby Vojčík wrote:
Hello,
to make things more DRY in spec and more consistent, what if
{some_content} in expression context would be defined as syntactic
sugar for (new Object).{some_content}?
No! You have just reintroduced the ES3 bug where a rebound or shadowed
Object can be used to
Brendan Eich wrote:
Herby Vojčík wrote:
Hello,
to make things more DRY in spec and more consistent, what if
{some_content} in expression context would be defined as syntactic
sugar for (new Object).{some_content}?
No! You have just reintroduced the ES3 bug where a rebound or shadowed
On Wed, May 30, 2012 at 10:32 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On May 29, 2012, at 10:05 PM, Rick Waldron wrote:
On Wednesday, May 30, 2012 at 12:00 AM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
Same thoughts here. Regular devs (like me!) only see
[[DefineOwnProperty]] when creating a literal, and then there's no
observable distinction between these two in normal circumstances:
Bingo. The different between [[DefineOwnProperty]] and
On May 29, 2012, at 9:59 AM, Nicholas C. Zakas wrote:
var element = document.getElementById(myDiv);
element.{
innerHTML: Hello world!,
className: enabled
};
Great example. With my proposed operator, it would instead be:
var element = document.getElementById(myDiv);
element.{
On Wed, May 30, 2012 at 5:22 PM, David Herman dher...@mozilla.com wrote:
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
Same thoughts here. Regular devs (like me!) only see
[[DefineOwnProperty]] when creating a literal, and then there's no
observable distinction between these two in
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
Given that these two are identical to most devs, giving them distinct
syntaxes in the strawman is problematic. Further, and much more
importantly, [[DefineOwnProperty]] is *nearly never* the behavior that
a dev will actually want. Devs are
On Wed, May 30, 2012 at 5:22 PM, David Herman dher...@mozilla.com wrote:
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
Same thoughts here. Regular devs (like me!) only see
[[DefineOwnProperty]] when creating a literal, and then there's no
observable distinction between these two in
Allen Wirfs-Brock wrote:
From that perspective I think isThisBound or just isBound is how
most people will think about it.
I think isBound wins in light of F.p.bind.
If you want to reverse the sense, I think it would be something like
hasDynamicThis or perhaps even isMethod (where by
Rick Waldron wrote:
In case anyone is interested, this syntax can be test driven using
Traceur, exactly as shown above:
Take a look at these screen shots:
Creating a div with innerHTML:
http://gyazo.com/50840d8fa61284af45817c0884094952.png
Multiple pop()s from an array:
On May 29, 2012, at 10:56 AM, Allen Wirfs-Brock wrote:
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
If it's desperately important that we don't make obj.{foo:bar} do a
[[Put]], then it would be much better to simply not allow that syntax
*at all*. ...
Language design and extension
Brendan Eich wrote:
Herby Vojčík wrote:
You need (need in the sense having readable construct to perform)
.{...} with [[DefineOwnProperty]] not for foo:bar (yes, there
[[Put]] should happen
No, again: JSON theft attack possible again with [[Put]]. Declarative
syntax is foo: bar. That means
On May 30, 2012, at 2:48 PM, Herby Vojčík wrote:
You need (need in the sense having readable construct to perform) .{...}
with [[DefineOwnProperty]] not for foo:bar (yes, there [[Put]] should
happen), but for dynamically adding concise methods and/or getters/setters to
objects.
Using
Mark S. Miller wrote:
I think that
o.{
p1: expr0,
p2() {return this.p1},
get p3 () {someSideEffect(); return this.p1}
};
and
o.(
p1 = expr1;
On May 29, 2012, at 9:00 PM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right
On May 30, 2012, at 2:18 PM, Mark S. Miller wrote:
However, there might be some utility (at least for debugging) in having a
Function.prototype.isThisBound method. It would return true for arrow
functions and functions created via Function.prototype.bind
I agree that such a predicate
On May 30, 2012, at 3:16 PM, Herby Vojčík wrote:
I can read literal extension in the same way: this is a bunch of data, make
the receiver object contain that data in it.
OK, but that agrees with my point, which is that the : doesn't carry an
operational connotation. To be specific, if the
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for can.
What guarantee are you trying
It is sound, as corrected in light of Allen's post. If the function
contains a direct eval operator in its body, it also might sense this.
On Wed, May 30, 2012 at 3:31 PM, David Herman dher...@mozilla.com wrote:
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm
On May 30, 2012, at 2:17 AM, T.J. Crowder wrote:
On 30 May 2012 05:09, Brendan Eich bren...@mozilla.org wrote:
...
So A remains
obj.{x: val, y: val};
...where these are [[DefineOwnProperty]]
and B becomes
obj.(x = val; y = val);
...where these are [[Put]]
Is the idea to
On May 30, 2012, at 4:00 PM, Axel Rauschmayer wrote:
I was mostly concerned about concise methods.
For most cases, you just want [[Put]]. And I favor thin arrow for concise
standalone methods/constructors.
How about the following use case? Adding a method with a super-reference to
an
At last week's meeting we deferred super outside of class methods.
/be
Axel Rauschmayer wrote:
How about the following use case? Adding a method with a super-reference to an
existing object.
___
es-discuss mailing list
es-discuss@mozilla.org
On Wednesday, May 30, 2012 at 6:31 PM, David Herman wrote:
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor
On May 30, 2012, at 4:15 PM, Brendan Eich wrote:
At last week's meeting we deferred super outside of class methods.
We talked about it, but I don't see the above statement captured in the
minutes. It also isn't clear what you mean by deferred. In a previous
message you said that
I have a question. Here (https://gist.github.com/9a6d60e9c15ac4239b3d) I took a
piece of existing boilerplate code and rewrote it using the new syntax. However
on L18 I have data-disqus-id that cannot be used on a left hand side of
assignment. What's a preferred way to deal with this? Move it
On Wed, May 30, 2012 at 4:34 PM, Anton Kovalyov m...@kovalyov.net wrote:
I have a question. Here (https://gist.github.com/9a6d60e9c15ac4239b3d) I
took a piece of existing boilerplate code and rewrote it using the new
syntax. However on L18 I have data-disqus-id that cannot be used on a left
Allen Wirfs-Brock wrote:
On May 30, 2012, at 4:15 PM, Brendan Eich wrote:
At last week's meeting we deferred super outside of class methods.
We talked about it, but I don't see the above statement captured in the minutes.
From Rick's notes of day 2:
AWB:
- Asserts that super is defined
On May 30, 2012, at 3:26 PM, David Herman wrote:
To be clear, my position is:
obj.{ x: 1, y: 2 } // over my dead body
obj.={ x: 1, y: 2 } // as [[DefineOwnProperty]], OK, but I'm not sure
it's worth it
obj.{ x = 1; y = 2 } // as [[Put]], I'm cool with it
Well, I don't
On Wednesday, May 30, 2012 at 7:40 PM, Tab Atkins Jr. wrote:
On Wed, May 30, 2012 at 4:34 PM, Anton Kovalyov m...@kovalyov.net wrote:
I have a question. Here (https://gist.github.com/9a6d60e9c15ac4239b3d) I
took a piece of existing boilerplate code and rewrote it using the new
syntax.
On Wed, May 30, 2012 at 4:54 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wednesday, May 30, 2012 at 7:40 PM, Tab Atkins Jr. wrote:
If you use the dataset API, like you should, there's no problem:
widget.{
...
dataset.disqusId = dsq1;
};
Maybe Dave can clarify, but I think it would
Thanks. I've updated my gist. I personally think that Rick's suggestion works
better in this case because it makes the whole tree of properties more visible.
But, at this point, it's just a styling issue.
Anton
On Wednesday, May 30, 2012 at 5:03 PM, Tab Atkins Jr. wrote:
On Wed, May 30,
Tab Atkins Jr. wrote:
On Wed, May 30, 2012 at 4:54 PM, Rick Waldronwaldron.r...@gmail.com wrote:
On Wednesday, May 30, 2012 at 7:40 PM, Tab Atkins Jr. wrote:
If you use the dataset API, like you should, there's no problem:
widget.{
...
dataset.disqusId = dsq1;
};
Maybe Dave can clarify, but
Allen Wirfs-Brock wrote:
I now could be quite happy with the paren based cascade idea that
Brendan suggested last night. I'm surprised that no one has commented
on the bnf I provided in a subsequent message.
Grammar is a detail at this point. The objection to parens is reasonable
enough:
On May 30, 2012, at 4:42 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On May 30, 2012, at 4:15 PM, Brendan Eich wrote:
At last week's meeting we deferred super outside of class methods.
We talked about it, but I don't see the above statement captured in the
minutes.
From Rick's
Allen Wirfs-Brock wrote:
Ultimately, I think we will find that we can't have a semantics like|super|
that is only usable within a syntactic class definition but has no reflective
support and no way way to programmatically desugar a class definition into the
exact equivalent set of object
On Wed, May 30, 2012 at 5:24 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Here is what I see. At the meeting, we decide to look at a mustache that
addressed two generally orthogonal sets of use cases. We looked at that and
found significant issues in using one construct for both sets
On May 30, 2012, at 5:14 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I now could be quite happy with the paren based cascade idea that Brendan
suggested last night. I'm surprised that no one has commented on the bnf I
provided in a subsequent message.
Grammar is a detail at this
Allen Wirfs-Brock wrote:
obj.(
deep.(
deeper: val;
deeper2: val2
)
)
They look different, but it's not clear to me that it looks bad. I
would use = instead of : because we are really just factoring
expressions and = is the operator that we are dealing with.
Argh, I meant to
On May 30, 2012, at 5:31 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Ultimately, I think we will find that we can't have a semantics like|super|
that is only usable within a syntactic class definition but has no
reflective support and no way way to programmatically desugar a class
On May 30, 2012, at 5:33 PM, Tab Atkins Jr. wrote:
On Wed, May 30, 2012 at 5:24 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Here is what I see. At the meeting, we decide to look at a mustache that
addressed two generally orthogonal sets of use cases. We looked at that and
found
On May 30, 2012, at 5:43 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
obj.(
deep.(
deeper: val;
deeper2: val2
)
)
They look different, but it's not clear to me that it looks bad. I would
use = instead of : because we are really just factoring expressions and =
is
Allen Wirfs-Brock wrote:
These are both subjective judgments.
What, other than grammatical ambiguity or other soundness problems, is
not in this kind of design?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
70 matches
Mail list logo
