Hi everyone,
This is almost purely a syntactic sugar proposal, and if there's already a
proposal like this being/been discussed, please point me that way, I
couldn't find anything. Anyway, the use case is as follows:
You have keys that come, for example from a config file or are defined as
2013/7/19 Jussi Kalliokoski jussi.kallioko...@gmail.com
myObject = {
someKey: 'someValue',
[MY_KEY_ID]: 'my value'
};
I believe this is already proposed at
http://wiki.ecmascript.org/doku.php?id=harmony%3Aobject_literals#object_literal_computed_property_keys
David
These are computed properties and Allen has already added them to the
latest ES6 draft.
ComputedPropertyName :
[ AssignmentExpression ]
Rick
On Fri, Jul 19, 2013 at 7:09 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Hi everyone,
This is almost purely a syntactic sugar
Yes - but I believe computed property names are currently spec'ed to throw
if the assignment expression evaluates to something other than a symbol
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Jul 19, 2013 at 9:10 AM, Kevin Smith zenpars...@gmail.com wrote:
Yes - but I believe computed property names are currently spec'ed to throw
if the assignment expression evaluates to something other than a symbol
Can you point to where the current spec draft specifies this—I don't see
Erik Arvidsson wrote:
This can either be done by exposing an object that has the same
interface as Date. This could throw on set or it could skip the set
methods entirely. If you want instanceof to work then all the methods
needs to be overridden.
Overriding the methods on a real date object
Sure - page 129 of the latest draft:
ComputedPropertyName : [ AssignmentExpression ]
1. Let exprValue be the result of evaluating AssignmentExpression.
2. Let propName be GetValue(exprValue).
3. ReturnIfAbrupt(propName).
4. If propName is not an exotic Symbol Object, then
a. Throw a
Domenic Denicola wrote:
I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
would do the trick, since `Object.freeze` seems to set all property keys to
non-writable/non-configurable.
This seems like it would be a backward-compatible change. But it's so simple
I
On Fri, Jul 19, 2013 at 5:11 PM, Kevin Smith zenpars...@gmail.com wrote:
Sure - page 129 of the latest draft:
ComputedPropertyName : [ AssignmentExpression ]
1. Let exprValue be the result of evaluating AssignmentExpression.
2. Let propName be GetValue(exprValue).
3.
right, this is listed in the agenda for the next TC39 meeting
If anybody can find in the TC39 meeting notes this was last discussed, that
would be helpful. I think in was in 2011 or early 2012.
allen
On Jul 19, 2013, at 8:22 AM, Till Schneidereit wrote:
On Fri, Jul 19, 2013 at 5:11 PM,
On Jul 19, 2013, at 7:53 AM, Nathan Wall wrote:
Domenic Denicola wrote:
I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
would do the trick, since `Object.freeze` seems to set all property keys to
non-writable/non-configurable.
This seems like it would be a
On Fri, Jul 19, 2013 at 11:32 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
right, this is listed in the agenda for the next TC39 meeting
If anybody can find in the TC39 meeting notes this was last discussed,
that would be helpful. I think in was in 2011 or early 2012.
Potentially
On Jul 19, 2013, at 7:07 AM, Andreas Rossberg wrote:
How do we move forward? Unfortunately, I won't make it to the meeting
next week...
At this point, the spec. is in a state where it is fairly easy to either stick
with symbols as exotic objects or switch to symbols as a primitive type
On Jul 19, 2013, at 6:51 AM, Andreas Rossberg wrote:
On 18 July 2013 17:53, Brendan Eich bren...@mozilla.com wrote:
3. Value object approach: no Symbol wrapper, typeof says symbol, spec
treats symbol as exotic object per latest draft.
The implementation cost of every new exotic object
On Jul 19, 2013, at 6:54 AM, Andreas Rossberg wrote:
On 18 July 2013 18:16, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
In fact, the
conclusion/resolution doesn't even say that Symbols will be primitive
values. All of the bullet items listed there are apply equally to either
symbols
On Fri, Jul 19, 2013 at 11:48 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Jul 19, 2013, at 6:54 AM, Andreas Rossberg wrote:
On 18 July 2013 18:16, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
In fact, the
conclusion/resolution doesn't even say that Symbols will be
On Jul 19, 2013, at 9:31 AM, Andreas Rossberg wrote:
On 19 July 2013 18:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You have to be able to support Proxy exotic objects so, I don't see why you
won't use that exact mechanism for Symbol objects.
Because they are different. There is no
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw andyearns...@gmail.com wrote:
It's potentially a breaking change, because
0 1 1
evaluates to false in current implementations because
(0 1) 1
Luckily, this is false in the chained operations too, since (0 1)
(1 1) evaluates to false.
On Fri, Jul 19, 2013 at 12:31 PM, Andreas Rossberg rossb...@google.comwrote:
On 19 July 2013 18:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
You have to be able to support Proxy exotic objects so, I don't see why
you won't use that exact mechanism for Symbol objects.
Because they are
On 7/19/2013 9:52 AM, Allen Wirfs-Brock wrote:
Even if you could, I highly doubt that proxy performance will ever be
up for the task, at least not for an implementation cost that isn't
much higher than the special casing.
Like I said, I don't see how this is a performance issue for Symbols
On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw andyearns...@gmail.com
wrote:
It's potentially a breaking change, because
0 1 1
evaluates to false in current implementations because
(0 1) 1
Luckily,
On Fri, Jul 19, 2013 at 2:48 PM, Andreas Rossberg rossb...@google.comwrote:
On 19 July 2013 19:41, Dean Landolt d...@deanlandolt.com wrote:
I'm curious how symbols differ semantically from null-prototype, empty,
frozen objects?
They differ in that the extra cruft that's needed to represent
On Fri, Jul 19, 2013 at 1:48 PM, Andreas Rossberg rossb...@google.com wrote:
On 19 July 2013 19:41, Dean Landolt d...@deanlandolt.com wrote:
I'm curious how symbols differ semantically from null-prototype, empty,
frozen objects?
They differ in that the extra cruft that's needed to represent
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw andyearns...@gmail.com
wrote:
It's potentially a breaking change, because
0 1 1
Another factor I haven't seen mentioned but that I think is important is
introducing a new primitive that has no literal form is another rough
edge/inconsistency that will be confusing. Having to use a factory to
make them makes me want to use `new` with that factory. But using `new`
should
On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Fri, Jul 19, 2013 at 1:35 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, Jul 18, 2013 at 4:34 PM, Andy Earnshaw
On Jul 19, 2013, at 11:37 AM, Andreas Rossberg wrote:
On 19 July 2013 18:52, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jul 19, 2013, at 9:31 AM, Andreas Rossberg wrote:
You can't use proxies for symbols -- they are special in parts of the
semantics (and that includes their wrappers,
On Fri, Jul 19, 2013 at 2:22 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron waldron.r...@gmail.com
wrote:
While this is all true, the simple answer is:
var a = 1, b =
On 19 Jul 2013 20:21, Tab Atkins Jr. jackalm...@gmail.com wrote:
Well, that's a bad example, because it's true with chained operators
too. Let c = 1.5, though, and you get different behavior.
This type of code is broken in the first place, though. Are we
assuming that it's prevalent enough
Allen Wirfs-Brock wrote:
Nathan Wall wrote:
Last time I asked, `Object.freeze` friends don't affect existing symbol
properties on an object (though new ones can't be added). I think this is
pretty important. Has this changed?
Object.freeze and friends affect all properties in the same
On Fri, Jul 19, 2013 at 5:43 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jul 19, 2013 at 2:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Fri, Jul 19, 2013 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Jul 19, 2013 at 1:21 PM, Rick Waldron
On Fri, Jul 19, 2013 at 4:18 PM, Rick Waldron waldron.r...@gmail.com wrote:
It doesn't matter if the parsing isn't exposed, or broken in the first
place, or a bad example, or not what you want, there is a formally defined
grammar in a published standard. Hopefully I've cleared up any remaining
I'd like to see this implemented, at least for greater/less than (-or equal
to).
a b c
a = b = c
Desugars to
a b b c
a = b b = c
As a workaround, consider that ES6 arrow functions are going to
make something like this readable:
function sortedBy(op,...args) {
Brandon Benvie wrote:
Another factor I haven't seen mentioned but that I think is important
is introducing a new primitive that has no literal form is another
rough edge/inconsistency that will be confusing. Having to use a
factory to make them makes me want to use `new` with that factory. But
On Jul 19, 2013, at 6:02 PM, Brendan Eich wrote:
Brandon Benvie wrote:
Another factor I haven't seen mentioned but that I think is important is
introducing a new primitive that has no literal form is another rough
edge/inconsistency that will be confusing. Having to use a factory to make
35 matches
Mail list logo
