, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Sun, Mar 18, 2018 at 7:06 PM, Felipe Nascimento de Moura
> wrote:
> > So, let's say you want a new object containing only some of the
> properties from another object.
>
> This has come up repea
On Sun, Mar 18, 2018 at 7:06 PM, Felipe Nascimento de Moura
wrote:
> So, let's say you want a new object containing only some of the properties
> from another object.
This has come up repeatedly, including very recently (most recent post today):
https://esdiscuss.org/topic/expan
So, let's say you want a new object containing only some of the properties
from another object.
For example, if I have the Object1 like this:
o1 = {
a: 1,
b: 2,
c: 3,
d: 4,
e: 5
}
And I want another object containing Object1's *b*, *c*, and *e*.
I could:
o2 = {...o1} // a
In my proposal, there are two syntaxes related to "deep" or "nested"
picking.
Assuming:
```js
var obj = {a: {b: 1, c: 2}, d: 3};
```
Inside the picking construct, the dot does a "deep pick":
```
obj.{a.b} // { b: 1 }
```
The colon does a "nested pick":
```
obj.{a: {b}} // { a: {b: 1}}
```
Bo
Viktor Kronvall schrieb:
What would this do?
```
let newObj = {obj.a.b}
```
`{a: {b: obj.a.b}}`
or
`{a: obj.a.b}`?
Or should nested property access be disallowed?
Neither - `obj.a.b` is `(obj.a).b`, so it's equivalent to `let newObj =
{b: obj.a.b}`.
The spec would basically be something lik
Zacqary Adam Xeper wrote:
But if I want to initialize a new object that pulls in just the foo and bar
properties, I have to type this whole structure out:
let newObj = {foo: obj.foo, bar: obj.bar, quux: 4}
Or, if I want to use shorthand property names, I can use a destructuring
statement, but
let's say I have:
>> let obj = {foo: 1, bar: 2, baz: 3}
>>
>> And I want to initialize a new object that looks like:
>> {foo: obj.foo, bar: obj.bar, quux: 4}
>>
>> I can create a new object with ALL of these properties using a spread
>> operator:
>&
tests.
>
> Regards,
> Bob Myers
>
> On Fri, Feb 19, 2016 at 11:02 PM, Zacqary Adam Xeper <
> zacqary.xe...@datadoghq.com> wrote:
>
>> So let's say I have:
>> let obj = {foo: 1, bar: 2, baz: 3}
>>
>> And I want to initialize a new object that
>
> I can create a new object with ALL of these properties using a spread
> operator:
> let newObj = {...obj, quux: 4}
>
Let's not do this.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t 11:02 PM, Zacqary Adam Xeper <
zacqary.xe...@datadoghq.com> wrote:
> So let's say I have:
> let obj = {foo: 1, bar: 2, baz: 3}
>
> And I want to initialize a new object that looks like:
> {foo: obj.foo, bar: obj.bar, quux: 4}
>
> I can create a new object w
Please see https://github.com/sebmarkbage/ecmascript-rest-spread
On Fri, Feb 19, 2016 at 11:32 AM, Zacqary Adam Xeper <
zacqary.xe...@datadoghq.com> wrote:
> So let's say I have:
> let obj = {foo: 1, bar: 2, baz: 3}
>
> And I want to initialize a new object that looks lik
So let's say I have:
let obj = {foo: 1, bar: 2, baz: 3}
And I want to initialize a new object that looks like:
{foo: obj.foo, bar: obj.bar, quux: 4}
I can create a new object with ALL of these properties using a spread
operator:
let newObj = {...obj, quux: 4}
But if I want to initialize
Pointing out that I'm replying to a message with an empty subject - using
the correct original title here
-- Forwarded message --
From: Rock
Benjamin Gruenaum, Andrea Giammarchi, you are wrong about RegExp:
```js
var re = /./;
new RegExp(re) === re; // false
RegExp(re) === re; //
JS is very much like writing with a pen (traditionally speaking). We can only
try to make less errors
as we move forward, but what’s there it’s there and it’s either too expensive
or impossible to change.
> On Jun 13, 2015, at 7:33 AM, Allen Wirfs-Brock wrote:
>
>
> On Jun 12, 2015, at 2:4
On Jun 12, 2015, at 2:47 PM, Benjamin Gruenaum wrote:
> That's good to know and it's good to know I'm not the first one to spot this.
>
> While we're visiting the spec on that:
>
> Why is it specified that "When called as a constructor it creates a new
> ordinary object. When Object is called
t; constructors in this same manner.
>
> Allen
>
>
>
>
>
>
>
> On Jun 12, 2015, at 1:19 PM, Benjamin Gruenaum wrote:
>
> Ok, so I gave this a few hours in the open.
>
> So, I'm looking at the ES5 specification (also checked the current ES
> draft wh
the open.
>
> So, I'm looking at the ES5 specification (also checked the current ES draft
> which is similar) at the definition of what new Object and Object do. To my
> surprise:
>
> - `new Object` describes a whole algorithm of how the object constructor
> works
ndeed if you try even minifiers, you'll notice that code like this
```js
this.bla = new Object(parent.foreignObject);
```
will be minified as
```js
this.bla=Object(parent.foreignObject);
```
On Fri, Jun 12, 2015 at 11:09 PM, Benjamin Gruenaum
wrote:
> Thanks, Array and Function (as w
gt;> Ok, so I gave this a few hours in the open.
>>
>> So, I'm looking at the ES5 specification (also checked the current ES
>> draft which is similar) at the definition of what new Object and Object do.
>> To my surprise:
>>
>> - `new Object` describes a w
un 12, 2015 at 10:19 PM, Benjamin Gruenaum
wrote:
> Ok, so I gave this a few hours in the open.
>
> So, I'm looking at the ES5 specification (also checked the current ES
> draft which is similar) at the definition of what new Object and Object do.
> To my surprise:
>
> -
Ok, so I gave this a few hours in the open.
So, I'm looking at the ES5 specification (also checked the current ES draft
which is similar) at the definition of what new Object and Object do. To my
surprise:
- `new Object` describes a whole algorithm of how the object constructor
works - tre
the unlikely cases
> described above, or can trigger a setter, and therefore may require
> your JS engine to check something each time you do it. That's extra
> work and it could slow things down.
>
> - The JS engine might be smart enough (if not now, then a year down
> the r
ect created by `return
{value: v, done: false};`. If it does, then using a new object is
probably better for your JS engine's optimizer, because getting .value
or .done off of that object is *guaranteed* to produce `v` and
`false`, respectively, with no side effects and no possibility of
tr
Well, if the user caches the result (in order to pass it to another
iterator) they'll get unexpected results.
Iterator A yields:
```js
{value: 1, done: false}
{value: 2, done: false}
{value: 3, done: false}
{value: 4, done: false}
```
There are two consumers for the iterator (sending the result
Seems handy for low allocation, performance critical iterators. As long as
the contract was clear, I would love something like this.
On Feb 28, 2015 5:52 PM, "Mark Volkmann" wrote:
> I know there was a discussion about this recently, but I don't recall
> seeing a reason why it would be problem fo
I know there was a discussion about this recently, but I don't recall seeing a
reason why it would be problem for a custom iterator to return the same object
over and over with different values for the value and done properties. I tried
this in some sample code using Traceur and Babel and it wor
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
ts 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 [[P
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
wo in normal circumstances:
Bingo. The different between [[DefineOwnProperty]] and [[Put]] is subtle and
rarely encountered when dealing with a new object.
The distinction between the two operations is a corner case of the language,
and [[Put]] is the common case.
I don't think it's w
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
n between these two in normal circumstances:
>
> Bingo. The different between [[DefineOwnProperty]] and [[Put]] is subtle
> and rarely encountered when dealing with a new object.
>
> The distinction between the two operations is a corner case of the
> language, and [[Put]] is
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
n between these two in normal circumstances:
>
> Bingo. The different between [[DefineOwnProperty]] and [[Put]] is subtle
> and rarely encountered when dealing with a new object.
>
> The distinction between the two operations is a corner case of the
> language, and [[Put]] is
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
ineOwnProperty]] and [[Put]] is subtle and
rarely encountered when dealing with a new object.
The distinction between the two operations is a corner case of the language,
and [[Put]] is the common case.
> I don't think it's worth optimizing for the [[DefineOwnProperty]]
> case. W
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
e Allen's new strawman.
By basically saying "what is inside .{...} does same things as what is
inside {...} and Allen said a few posts before that spec is already
written that way ({...} is (new Object).{...}).
So, established as legacy from (extended) object literals.
I cannot see
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
1 - 100 of 208 matches
Mail list logo
