T.J. Crowder wrote:
My point is that the discussion of object extension literals was
clearly headed toward being a new `with`,
No, this is what Dave was objecting to. It's careless to say "new
'with'" if you do not mean dynamic scope, specifically object on the
scope chain. No one meant that, a
On 31 May 2012 19:21, Brendan Eich wrote:
> Thanks, Dave.
>
> Bottom-citing here, and again I'm a sinner too, but could everyone on this
> nicely long thread take a breath and remember two things:
>
> 1. We aren't going to reform 'with' for ES6 or Harmony. It's banned in
> strict mode, there due
Thanks, Dave.
Bottom-citing here, and again I'm a sinner too, but could everyone on
this nicely long thread take a breath and remember two things:
1. We aren't going to reform 'with' for ES6 or Harmony. It's banned in
strict mode, there due to 1JS in the non-strict mode of the language,
not
On May 31, 2012, at 2:52 AM, T.J. Crowder wrote:
> I'm worried this looks a lot like `with` -- with the same issues.
No. No.
This does not involve the object with the scope chain in any way.
> Is the idea that unqualified references would be _required_ to be properties
> of the object in q
On Thu, May 31, 2012 at 6:05 AM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
> On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
> wrote:
>
>> On 31 May 2012 10:44, Andreas Rossberg wrote:
>>
>>> On 30 May 2012 23:34, David Herman wrote:
>>> > On May 30, 2012, at 2:27 PM, Rick Waldron
On Wed, May 30, 2012 at 8:40 PM, Allen Wirfs-Brock wrote:
>
> 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
>
I really like(d) the mustache proposal but unfortunately reached the
same conclusion : too complicate and confusing for what it brings. It's
surprising that the fundamental difference between Put and DOP was
unknown from almost everybody (including myself), then a rapid and easy
conclusion know
On 31 May 2012 11:30, François REMY wrote:
> o.{
>>a.b = 6;
>>c.f();
>>a.b = a.c; // !!
>> };
>>
>
> This is indeed an issue that could be solved using
>
> o.{
> .a.b = 6;
> .c.f();
> .a.b = .a.c;
> }
Exactly my thought, and as it happens I was just writing it
o.{
a.b = 6;
c.f();
a.b = a.c; // !!
};
This is indeed an issue that could be solved using
o.{
.a.b = 6;
.c.f();
.a.b = .a.c;
}
My previous sample would be rewritten :
var style = "color: red";
var elem = document.createElement("span");
elem.{
On 31 May 2012 11:18, T.J. Crowder wrote:
> On 31 May 2012 11:05, Jussi Kalliokoski wrote:
>
>> On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
>> wrote:
>>
>>> On 31 May 2012 10:44, Andreas Rossberg wrote:
>>>
On 30 May 2012 23:34, David Herman wrote:
> On May 30, 2012, at 2:27 PM, R
On 31 May 2012 11:05, Jussi Kalliokoski wrote:
> On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder
> wrote:
>
>> On 31 May 2012 10:44, Andreas Rossberg wrote:
>>
>>> On 30 May 2012 23:34, David Herman wrote:
>>> > On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
>>> >
>>> > On Wed, May 30, 2012 a
From: T.J. Crowder
I'm worried this looks a lot like `with` -- with the same issues. Is the
idea that unqualified references would be _required_ to be properties of
the object in question?
This looks like a with regarding some points, but this is cleary not a with.
I think
var style =
On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder wrote:
> On 31 May 2012 10:44, Andreas Rossberg wrote:
>
>> On 30 May 2012 23:34, David Herman wrote:
>> > On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
>> >
>> > On Wed, May 30, 2012 at 5:22 PM, David Herman
>> wrote:
>> >>
>> >>
>> >>array
On 31 May 2012 10:44, Andreas Rossberg wrote:
> On 30 May 2012 23:34, David Herman wrote:
> > On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
> >
> > On Wed, May 30, 2012 at 5:22 PM, David Herman
> wrote:
> >>
> >>
> >>array.{
> >>pop();
> >>pop();
> >>pop();
> >>
On 30 May 2012 23:34, David Herman wrote:
> On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
>
> On Wed, May 30, 2012 at 5:22 PM, David Herman wrote:
>>
>>
>> array.{
>> pop();
>> pop();
>> pop();
>> };
>>
>> path.{
>> moveTo(10, 10);
>> stroke("red");
On 30 May 2012 22:33, Mark S. Miller wrote:
> My concern is indeed the overall complexity budget. And I agree. I'm happy
> to have both of these if we can make some real complexity cuts elsewhere. I
> look forward to that other conversation ;).
I have the same concern. The syntactic complexity an
Allen Wirfs-Brock wrote:
On May 30, 2012, at 4:42 PM, Brendan Eich wrote:
What we agreed to last week: no |super| outside of classes in ES6,
no Object.defineMethod in ES6. That's what I recall and what the
notes say (re: |super|).
I also don't see the mention of defineMethod although I know
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
https://mail.mozilla.org/listinf
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 fac
On May 30, 2012, at 5:33 PM, Tab Atkins Jr. wrote:
> On Wed, May 30, 2012 at 5:24 PM, Allen Wirfs-Brock
> 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 i
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 cl
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: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 deta
On Wed, May 30, 2012 at 5:24 PM, Allen Wirfs-Brock
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 of use cases.
>
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 def
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.
>
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: the
Tab Atkins Jr. wrote:
On Wed, May 30, 2012 at 4:54 PM, Rick Waldron 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 act
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, 20
On Wed, May 30, 2012 at 4:54 PM, Rick Waldron 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 actuall
On Wednesday, May 30, 2012 at 7:40 PM, Tab Atkins Jr. wrote:
> On Wed, May 30, 2012 at 4:34 PM, Anton Kovalyov 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 L
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 do
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 co
On Wed, May 30, 2012 at 4:34 PM, Anton Kovalyov 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
> hand side of ass
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 to
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 @private
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
https:/
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
On May 30, 2012, at 2:17 AM, T.J. Crowder wrote:
> On 30 May 2012 05:09, Brendan Eich 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 _only_ ha
>> 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
existing object.
--
Dr. Axel Rauschmayer
a...@rausch
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 t
David Herman wrote:
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
Mark S. Miller wrote:
I think that
o.{
p1: expr0,
p2() {return this.p1},
get p3 () {someSideEffect(); return this.p1}
};
and
o.(
p1 = expr1;
p2()
Herby Vojčík wrote:
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
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.
>
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 m
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 define not assig
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 API is much more cumbersome here. And lots of bugs c
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 an
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:
http://gyazo.com/5303
On Wed, May 30, 2012 at 5:22 PM, David Herman 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 normal circu
On May 30, 2012, at 2:27 PM, Rick Waldron wrote:
> On Wed, May 30, 2012 at 5:22 PM, David Herman wrote:
>
>array.{
>pop();
>pop();
>pop();
>};
>
>path.{
>moveTo(10, 10);
>stroke("red");
>fill("blue");
>ellipse(50, 50);
>};
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
On Wed, May 30, 2012 at 5:22 PM, David Herman 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 normal circu
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");
elemen
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]] an
On Wed, May 30, 2012 at 3:46 PM, Allen Wirfs-Brock wrote:
> 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 a
On Wed, May 30, 2012 at 12:46 PM, Allen Wirfs-Brock
wrote:
> 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
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
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
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:
MemberEx
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 "w
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
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 w
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.
B.
, May 30, 2012 11:17 AM
To: Brendan Eich ; es-discuss@mozilla.org
Subject: Re: New Object Extension Literal Strawman
On 30 May 2012 05:09, 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
On 30 May 2012 05:09, 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 mustac
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.
___
e
On Tue, May 29, 2012 at 11:19 PM, Brendan Eich 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 go
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 than
semicolon" in light of object literals having different-enough
bracke
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: va
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
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.
B. obj.[prop = val; ...
On 5/29/2012 11:03 AM, Brendan Eich wrote:
Therefore I believe that if we can't agree on = and : both having
support in mustache, we should use different-enough looking syntax, a
la Dave's misplaced gist for fluent style, and not get stuck here and
end up with nothing.
That was basically my
On 5/29/2012 10:56 AM, Allen Wirfs-Brock wrote:
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
On Tue, May 29, 2012 at 9:45 AM, Mark S. Miller wrote:
Language design and extension is a complex process. Being supportive of multiple use cases generally makes a new
feature more valuabl
On Tue, May 29, 2012 at 11:03 AM, Brendan Eich wrote:
> Tab Atkins Jr. wrote:
>> I'm not making the assumption that "obj" in the examples is
>> necessarily an Object with Object.prototype. It's irrelevant to the
>> two points I'm trying to make:
>>
>> 1. The use-case for mustache is to replace cu
I already have the specification semantics setup to work that way. It is
really only the syntax rules that distinguishes the two forms.
On May 29, 2012, at 11:54 AM, Herby Vojčík wrote:
> Hi,
>
> I sent the mail in attachment to the list, but it did not arrive yet, so I
> send it this way. I
On Tue, May 29, 2012 at 11:03 AM, Brendan Eich wrote:
> Fair points so far, and why Dave Herman proposed using = and ; separation
> for a "fluent style" chaining extension:
>
> obj.{
> prop1 = val1;
> ...
> propN = valN;
> };
>
> Dave's proposal (which I can't find atm, it may be in a g
Hi,
I sent the mail in attachment to the list, but it did not arrive yet, so
I send it this way. It is exactly about making those two spec-wise the
same thing. What do you think of it (since it DRYes it, it would not
complicate the proposal and the resulting spec and language could have
the c
On Tue, May 29, 2012 at 11:30 AM, Allen Wirfs-Brock
wrote:
>
> On May 29, 2012, at 11:17 AM, Herby Vojčík wrote:
>
> > Couldn't all this be solved by allowing = also for object literals and
> promoting its use? People get used to the fact that = is the "normal" way
> and : is the "special" way plu
On May 29, 2012, at 11:17 AM, Herby Vojčík wrote:
> Couldn't all this be solved by allowing = also for object literals and
> promoting its use? People get used to the fact that = is the "normal" way and
> : is the "special" way plus they are told JSON only has : for both historical
> and secur
Herby Vojčík wrote:
Couldn't all this be solved by allowing = also for object literals and
promoting its use? People get used to the fact that = is the "normal"
way and : is the "special" way plus they are told JSON only has : for
both historical and security reasons.
Because I feel the main
Allen Wirfs-Brock wrote:
It seems that understanding the difference between defining a property and
assigning to a property is a distinction that JS developers need to learn.
Particularly, as object definition patterns migrate away from definition via
assignment to more declarative forms (clas
Couldn't all this be solved by allowing = also for object literals and
promoting its use? People get used to the fact that = is the "normal"
way and : is the "special" way plus they are told JSON only has : for
both historical and security reasons.
Because I feel the main problem felt here is
On May 29, 2012, at 10:43 AM, Axel Rauschmayer wrote:
>> Beware scenario-solving in an all-or-nothing way. There's no absolute good
>> here, and while people may (due to Prototype's Object.extend) want = not :
>> in most cases, that doesn't mean : is unnecessary.
>
> Define properties manually
Tab Atkins Jr. wrote:
On Tue, May 29, 2012 at 10:21 AM, Brendan Eich wrote:
Tab Atkins Jr. wrote:
Make monocle-mustache solely use the "obj.{foo=bar}"
syntax, so that the other one is a syntax error. There's no good
reason to give devs the other type of functionality besides
completeness, and
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
> On Tue, May 29, 2012 at 9:45 AM, Mark S. Miller wrote:
>> The use of foo:bar in object literals and in JSON
>> causes [[DefineOwnProperty]] behavior, not [[Put]] behavior. Making
>> mustache's treatment of foo:bar inconsistent with object lit
Axel Rauschmayer wrote:
Beware scenario-solving in an all-or-nothing way. There's no absolute good
here, and while people may (due to Prototype's Object.extend) want = not : in
most cases, that doesn't mean : is unnecessary.
Define properties manually when you really need it? I agree with Zak
On Tue, May 29, 2012 at 10:21 AM, Brendan Eich wrote:
> Tab Atkins Jr. wrote:
>> Make monocle-mustache solely use the "obj.{foo=bar}"
>> syntax, so that the other one is a syntax error. There's no good
>> reason to give devs the other type of functionality besides
>> completeness, and using it wi
> Beware scenario-solving in an all-or-nothing way. There's no absolute good
> here, and while people may (due to Prototype's Object.extend) want = not : in
> most cases, that doesn't mean : is unnecessary.
Define properties manually when you really need it? I agree with Zakas et al.:
it will b
Allen Wirfs-Brock wrote:
On May 29, 2012, at 10:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
ES 5 defines "foo:bar" as meaning [[DefineOwnPropertuy]]. Prior to the standardization
of getter/setter semantics in ES5 some implementation used [[Put]] for "foo:bar".
They did that because
On May 29, 2012, at 10:15 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> ES 5 defines "foo:bar" as meaning [[DefineOwnPropertuy]]. Prior to the
>> standardization of getter/setter semantics in ES5 some implementation used
>> [[Put]] for "foo:bar".
>
> They did that because ES3 mandated
Tab Atkins Jr. wrote:
Make monocle-mustache solely use the "obj.{foo=bar}"
syntax, so that the other one is a syntax error. There's no good
reason to give devs the other type of functionality besides
completeness, and using it will almost always be a mistake on the
dev's part, I think.
Who say
Allen Wirfs-Brock wrote:
ES 5 defines "foo:bar" as meaning [[DefineOwnPropertuy]]. Prior to the standardization
of getter/setter semantics in ES5 some implementation used [[Put]] for "foo:bar".
They did that because ES3 mandated it!
This was indeed a bug in ES3.
That was identified as a
Nicholas C. Zakas wrote:
On 5/29/2012 9:45 AM, Brendan Eich wrote:
Note that the modern DOM and WebIDL are being spec'ed so typical DOM
accessors are on prototypes, so you can't "fix" the bug by using
[[Put]] only when the property is "own".
There really is a difference between assigning and
On 29 May 2012 17:59, Nicholas C. Zakas wrote:
> var element = document.getElementById("**myDiv");
> element.{
>innerHTML: "Hello world!",
>className: "enabled"
> };
>
> Going by the current definition, this code block would actually have no
> effect because it would be defining new own p
On Tue, May 29, 2012 at 9:45 AM, Mark S. Miller wrote:
> The use of foo:bar in object literals and in JSON
> causes [[DefineOwnProperty]] behavior, not [[Put]] behavior. Making
> mustache's treatment of foo:bar inconsistent with object literals and with
> JSON is a worse footgun. If you always wan
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
> On Tue, May 29, 2012 at 9:26 AM, Nicholas C. Zakas
> wrote:
>> Thanks for the clarifications. I understand wanting to make the distinction
>> from an implementer point of view,
It isn't really an implementation issue. This concerns some of t
On 5/29/2012 9:45 AM, Brendan Eich wrote:
Note that the modern DOM and WebIDL are being spec'ed so typical DOM
accessors are on prototypes, so you can't "fix" the bug by using
[[Put]] only when the property is "own".
There really is a difference between assigning and defining in JS.
Assigning
Nicholas C. Zakas wrote:
Thanks for the clarifications. I understand wanting to make the
distinction from an implementer point of view, I'm just not sure that
developers make the distinction between [[Put]] and
[[DefineOwnProperty]] even using regular object literals. Is there a
reason that th
1 - 100 of 108 matches
Mail list logo
