Object literal syntax for dynamic keys
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
constants, and you want to create objects with those keys. What you
currently have to do is to use a mix of object notation syntax and
assignment:
myObject = {
someKey: 'someValue'
};
myObject[MY_KEY_ID] = 'my value';
This is usually ok, but it's a bit confusing to read especially if the
object is long and you try to find the definition inside the brackets but
can't. Also, as far as I know, `someKey` and `MY_KEY_ID` end up being
defined differently; I doubt that the latter matters much, but what I have
in mind would fix both things:
myObject = {
someKey: 'someValue',
[MY_KEY_ID]: 'my value'
};
So basically you could use brackets to signify that the key is the value of
an expression inside the brackets.
Cheers,
Jussi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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 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
constants, and you want to create objects with those keys. What you
currently have to do is to use a mix of object notation syntax and
assignment:
myObject = {
someKey: 'someValue'
};
myObject[MY_KEY_ID] = 'my value';
This is usually ok, but it's a bit confusing to read especially if the
object is long and you try to find the definition inside the brackets but
can't. Also, as far as I know, `someKey` and `MY_KEY_ID` end up being
defined differently; I doubt that the latter matters much, but what I have
in mind would fix both things:
myObject = {
someKey: 'someValue',
[MY_KEY_ID]: 'my value'
};
So basically you could use brackets to signify that the key is the value
of an expression inside the brackets.
Cheers,
Jussi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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
Re: Object literal syntax for dynamic keys
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 it. Thanks Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Frozen Date objects?
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 (or one that inherits from Date but was constructed with the Date constructor) won't work because then Date.prototype.set* methods would still be able to mutate the internal date by calling them explicitly: var readOnlyDate = getReadOnlyDate(); readOnlyDate.setHours !== Date.prototype.setHours; // = true Date.prototype.setHours.call(readOnlyDate, 2); // oops Also, I don't think `insanceof` should be used to check Dates. If Object.prototype.toString is used, the object just needs to be tagged as a Date and the function used to determine whether an object is a date needs to take into consideration ~Date as well. Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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 TypeError exception.
5. Return propName.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Frozen Date objects?
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 imagine it's been discussed before. I await hearing where it falls down... 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? Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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. ReturnIfAbrupt(propName). 4. If propName is not an exotic Symbol Object, then a. Throw a TypeError exception. 5. Return propName. This isn't yet a final decision, however: http://esdiscuss.org/topic/on-ie-proto-test-cases#content-5 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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, 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. ReturnIfAbrupt(propName). 4. If propName is not an exotic Symbol Object, then a. Throw a TypeError exception. 5. Return propName. This isn't yet a final decision, however: http://esdiscuss.org/topic/on-ie-proto-test-cases#content-5 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
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 backward-compatible change. But it's so simple I imagine it's been discussed before. I await hearing where it falls down... 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 way, including symbol keyed properties. Allen Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object literal syntax for dynamic keys
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 relevant: Computed Property Names for Object Literals Were Abandoned… https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#computed-property-names-for-object-literals-were-abandoned decoupling [ ] and property access for collections https://mail.mozilla.org/pipermail/es-discuss/2011-October/017468.html Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 with a wrapper class. From a language design perspective, I think the implications WRT future value types is the most important consideration and that is what we need to explore. Are we going to have to provide a mechanism for user defined primitive types + wrappers if we go that route? I understand that in V8 you have cross-cutting implementation issues with symbols as objects. However there are also likely to be cross-cutting implementation issues for others relating to adding primitive types. I don't think either of these implementation perspectives should be the primary decision criteria. Instead, we should focus on the conceptual language design level. Which path will be better for the language and its users in the long run. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 is fairly substantial in a modern VM, due to cross-cutting. That's at least my experience from implementing the ones currently on the ES6 radar, proxies and symbols (not even considering optimisations). We should be _very_ conservative about introducing more of these than absolutely necessary. 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. In other words, use a self-hosted Proxy-based implementation for Symbol objects. The MOP operations on Symbol exotic objects in all cases either throw an exception or return some predetermined result such as undefined or false. These operations have little application utility (other than object model consistency) so there should be any perf. concerns about using a Proxy to define the symbol MOP behavior. Of course, you would still want to optimize for their use as property keys. While there are a few standard exotic objects that clearly need optimization, I would hope that most future ones could reasonably be implemented using Proxy. After all, that was one of the primary motivations for Proxy. If Proxies are only toys then we have wasted an lot of time on them. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 as primitives or symbols as exotic objects. The current (and previous, I believe) spec. draft reflects those explicit conclusions. Ah, come on. That was the main point of the proposal, and it's explicit at the beginning of the notes. It was clear to everybody in the room, including you. You went to adopt it in the spec, after all. Oh, I agree with that. I was just making a point that the minutes aren't always a very reliable record of a discussion. And that's not meant as a criticism of Rick or Arv or anybody else who takes notes. I couldn't do it half as well as they do. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 primitive values. All of the bullet items listed there are apply equally to either symbols as primitives or symbols as exotic objects. The current (and previous, I believe) spec. draft reflects those explicit conclusions. Ah, come on. That was the main point of the proposal, and it's explicit at the beginning of the notes. It was clear to everybody in the room, including you. You went to adopt it in the spec, after all. Oh, I agree with that. I was just making a point that the minutes aren't always a very reliable record of a discussion. And that's not meant as a criticism of Rick or Arv or anybody else who takes notes. I couldn't do it half as well as they do. Apologies for any ambiguity in the notes—I should've reiterated in the Conclusion/Resolution, but I distinctly remember that Andreas's proposal to make Symbols a new primitive was indeed accepted. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 useful unified mechanism for exotic objects, at least no efficient one. Every new form of exotic object will be a new special case. As I said, the nice spec-level MOP abstraction is largely irrelevant at the implementation level. I'm speaking from V8 experience here, but I would be surprised if the situation is much different in other modern VMs. In other words, use a self-hosted Proxy-based implementation for Symbol objects. The MOP operations on Symbol exotic objects in all cases either throw an exception or return some predetermined result such as undefined or false. You can't use proxies for symbols -- they are special in parts of the semantics (and that includes their wrappers, if we want them to be special, too). And I doubt that you will be able to use them for other exotic objects we might come up with (e.g. value objects would have special equality behaviour that proxies can't simulate). Note that I was talking about the symbols as exotic objects path, not the symbols as new primitive type path so there would be no wrappers. In what way are the object semantics of exotic symbol objects special such that couldn't be represented via a Proxy handler? The special behavior of symbols appears, to me to be all ready of operations that are not part of the MOP. Hashing for property lookup, comparison during lookup, etc. I still don't see why the Proxy MOP dispatch mechanism wouldn't be perfectly adequate for their generally pointless application to symbols. 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 exotic objects because the MOP operations are never important for them. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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. One problem is that in current Javascript, the equality and the comparison operators are at different precedence levels. Python puts them at the same level, so that chaining can be purely left-to-right. There's a decent chance that code does indeed depend on this, due to testing equality of a comparison with a bool (which is stupid, but people do it). ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 different. There is no useful unified mechanism for exotic objects, at least no efficient one. Every new form of exotic object will be a new special case. As I said, the nice spec-level MOP abstraction is largely irrelevant at the implementation level. I'm speaking from V8 experience here, but I would be surprised if the situation is much different in other modern VMs. In other words, use a self-hosted Proxy-based implementation for Symbol objects. The MOP operations on Symbol exotic objects in all cases either throw an exception or return some predetermined result such as undefined or false. You can't use proxies for symbols -- they are special in parts of the semantics (and that includes their wrappers, if we want them to be special, too). I'm curious how symbols differ semantically from null-prototype, empty, frozen objects? I can't think of any substantive differences other the power to act as object keys (and some seemingly insignificant details like toString behavior). If that's truly the case, wouldn't it be a lot easier to just allow any null-prototype, empty, frozen object to have the object-key capability? For consistency Object.prototype.toString could even be specified to return something along the lines of [object Symbol] for values which fulfill this criteria (a breaking change, but only very slightly -- I can't imagine this affecting code in the wild). And I doubt that you will be able to use them for other exotic objects we might come up with (e.g. value objects would have special equality behaviour that proxies can't simulate). 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. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 exotic
objects because the MOP operations are never important for them.
Indeed, a largely self-hosted implementation of Symbol could look like:
const UNDEFINED = () = {};
const TRUE = () = true;
const FALSE = () = false;
const NULL = () = null;
const ARRAY = () = [];
const symbolHandler = {
getOwnPropertyDescriptor: UNDEFINED,
getOwnPropertyNames: ARRAY,
getPrototypeOf: NULL,
setPrototypeOf: FALSE,
defineProperty: FALSE,
deleteProperty: TRUE,
freeze: TRUE,
seal: TRUE,
preventExtensions: TRUE,
isFrozen: TRUE,
isSealed: TRUE,
isExtensible: FALSE,
has: FALSE,
hasOwn: FALSE,
get: UNDEFINED
set: FALSE,
enumerate: ARRAY,
keys: ARRAY,
};
function Symbol(name){
const symbol = new Proxy({}, symbolHandler);
%MarkAsSymbol(symbol, name);
return symbol;
}
It's rare (and pointless) to perform MOP operations on a Symbol because
they're inert. There's no need to optimize those. The optimization that
has to happen is deciding when something is a symbol for the purposes of
property lookup.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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, this is false in the chained operations too, since (0 1) (1 1) evaluates to false. One problem is that in current Javascript, the equality and the comparison operators are at different precedence levels. Python puts them at the same level, so that chaining can be purely left-to-right. There's a decent chance that code does indeed depend on this, due to testing equality of a comparison with a bool (which is stupid, but people do it). While this is all true, the simple answer is: var a = 1, b = 2, c = 3; a b c; // true is already valid JavaScript and can't be co-opted to express new runtime evaluation semantics. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 random objects is a complete waste of space on them. Also, there is a performance benefit if they can share a common representation with strings, so that you don't need a case distinction in every place dealing with property names (e.g. wrt to hashing). In any case, I don't want to focus exclusively on the implementation. I also think that there are obvious semantic and usability reasons for making them as similar to existing types as possible (esp strings, which they are closely related to). I completely agree that it makes sense to keep them as similar as possible to existing types. in fact, I'm just extending your argument a bit, but picking one nit: symbols are more like objects than strings. Since they're only useful as keys what matters for our purposes is their unique, unforgeable identity, which they share in common with any other object. The only thing they have in common specifically with strings (and not other primitives) is the special capability to act as an object key. But again, what matters here is *how* -- their intensional identity is crucially different than the extensional identity of strings. There's no reason I know of why this capability of being able to key an object property couldn't be extended from strings to objects -- provided, of course, that the objects are completely stateless and frozen. Isn't this the very definition of a Symbol? A symbol is just a stateless frozen object -- do we really care what it toString's to? Once an object is stateless and frozen it can't be anything but stateless and frozen, thus any stateless frozen object could just as well be a symbol. Sure, the language can spec a Symbol constructor to make it easier to mint stateless frozen objects, but is there any difference? So if your ends is to keep symbols as close as possible to existing types I think suspect this approach does you one better -- it makes Symbols a perfect subtype of one of the built-ins -- just not the one you were thinking :) I can't think of any substantive differences other the power to act as object keys (and some seemingly insignificant details like toString behavior). If that's truly the case, wouldn't it be a lot easier to just allow any null-prototype, empty, frozen object to have the object-key capability? Unfortunately, making other objects into keys would break existing code that assumes a ToString conversion for those. Perhaps. I know it'd be breaking -- perhaps I'm not being imaginative enough about the kind of code it could break. I doubt I've written code that would break on this, but I've *definitely* written code that will break if the range from typeof is expended. Regardless, I doubt it'd even be useful to hack the spec for a special toString. Is there any reason a symbol's toString couldn't return [object Object]? if this is the only drawback to normalizing symbols in the way I suggest, it seems like a small price when all the other quibbles being debated melt away. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 random objects is a complete waste of space on them. Also, there is a performance benefit if they can share a common representation with strings, so that you don't need a case distinction in every place dealing with property names (e.g. wrt to hashing). In any case, I don't want to focus exclusively on the implementation. I also think that there are obvious semantic and usability reasons for making them as similar to existing types as possible (esp strings, which they are closely related to). I can't think of any substantive differences other the power to act as object keys (and some seemingly insignificant details like toString behavior). If that's truly the case, wouldn't it be a lot easier to just allow any null-prototype, empty, frozen object to have the object-key capability? Unfortunately, making other objects into keys would break existing code that assumes a ToString conversion for those. Thus Dean's suggestion of only allowing it for null-prototype, frozen, empty objects. These are exceedingly rare in the first place, because you have to jump through several hoops to create them. (I don't think I like Dean's suggestion, but I don't want incorrect assumptions getting thrown about.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 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. One problem is that in current Javascript, the equality and the comparison operators are at different precedence levels. Python puts them at the same level, so that chaining can be purely left-to-right. There's a decent chance that code does indeed depend on this, due to testing equality of a comparison with a bool (which is stupid, but people do it). While this is all true, the simple answer is: var a = 1, b = 2, c = 3; a b c; // true is already valid JavaScript and can't be co-opted to express new runtime evaluation semantics. 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 to cause problems? ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 always return an object from the builtins, ergo Symbols objects (whether wrappers or not) should be usable (either through auto-unwrapping or no primitive form) or some inconsistency or another will be introduced. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 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. One problem is that in current Javascript, the equality and the comparison operators are at different precedence levels. Python puts them at the same level, so that chaining can be purely left-to-right. There's a decent chance that code does indeed depend on this, due to testing equality of a comparison with a bool (which is stupid, but people do it). While this is all true, the simple answer is: var a = 1, b = 2, c = 3; a b c; // true is already valid JavaScript and can't be co-opted to express new runtime evaluation semantics. 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 to cause problems? It doesn't matter if you think my example is a bad example, it's a valid expression per the language's existing grammar. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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, if we want them to be special, too). And I doubt that you will be able to use them for other exotic objects we might come up with (e.g. value objects would have special equality behaviour that proxies can't simulate). Note that I was talking about the symbols as exotic objects path, not the symbols as new primitive type path so there would be no wrappers. In what way are the object semantics of exotic symbol objects special such that couldn't be represented via a Proxy handler? The special behavior of symbols appears, to me to be all ready of operations that are not part of the MOP. Hashing for property lookup, comparison during lookup, etc. I still don't see why the Proxy MOP dispatch mechanism wouldn't be perfectly adequate for their generally pointless application to symbols. That would at least require some way of distinguishing ordinary proxies from those internal symbol proxies, so that they can cheaply be recognised as symbols. Alas, a separate proxy type, or extra internal info you need to store in every proxy. Whether proxies are used or not, you still need to do make that distinction. An identify test on the proxy handler or target reference might be one cheap way to identify them. There are undoubtably many other possibilities. At the same time, proxies already come with a space overhead that you don't want to pay for symbols. No, I think that proxies would be total overkill here, and yet not even sufficient. This little subthread started with with you wanting to minimize the complex of another implementation level exotic object type. This is one way to do it. There are space and time trade-offs to be made but it definitely is not an absurd approach to consider. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 = 2, c = 3; a b c; // true is already valid JavaScript and can't be co-opted to express new runtime evaluation semantics. Well, that's a bad example, because it's true with chained operators too. Let c = 1.5, though, and you get different behavior. It doesn't matter if you think my example is a bad example, it's a valid expression per the language's existing grammar. It certainly does, because we don't expose the parsing directly. If we change the interpretation of a piece of code, but it outputs the same or compatible values, we're fine. It's only when the observable results change incompatibly that we have to worry. In your example, you get a true regardless of the interpretation, which means you're not demonstrating a problem with changing the interpretation. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 to cause problems? Well, I was hoping it wouldn't. I can't imagine anyone writing this kind of code unless they expect it to work in the same way as Python (and by chance it did when they tested). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Frozen Date objects?
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 way, including symbol keyed properties. Am I thinking of the behavior that was discussed for private symbols when they were a possibility? Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 waldron.r...@gmail.com
wrote:
While this is all true, the simple answer is:
var a = 1, b = 2, c = 3;
a b c; // true
is already valid JavaScript and can't be co-opted to express new
runtime
evaluation semantics.
Well, that's a bad example, because it's true with chained operators
too. Let c = 1.5, though, and you get different behavior.
It doesn't matter if you think my example is a bad example, it's a
valid
expression per the language's existing grammar.
It certainly does, because we don't expose the parsing directly. If
we change the interpretation of a piece of code, but it outputs the
same or compatible values, we're fine. It's only when the observable
results change incompatibly that we have to worry. In your example,
you get a true regardless of the interpretation, which means you're
not demonstrating a problem with changing the interpretation.
You have completely missed my point, please refer to the grammar
specification that has existed since the first edition, published in 1997:
MultiplicativeExpression :
UnaryExpression
MultiplicativeExpression * UnaryExpression
MultiplicativeExpression / UnaryExpression
MultiplicativeExpression % UnaryExpression
AdditiveExpression :
MultiplicativeExpression
AdditiveExpression + MultiplicativeExpression
AdditiveExpression - MultiplicativeExpression
ShiftExpression :
AdditiveExpression
ShiftExpression AdditiveExpression
ShiftExpression AdditiveExpression
ShiftExpression AdditiveExpression
RelationalExpression :
ShiftExpression
RelationalExpression ShiftExpression
RelationalExpression ShiftExpression
RelationalExpression = ShiftExpression
RelationalExpression = ShiftExpression
RelationalExpression instanceof ShiftExpression
RelationalExpression in ShiftExpression
EqualityExpression :
RelationalExpression
EqualityExpression == RelationalExpression
EqualityExpression != RelationalExpression
EqualityExpression === RelationalExpression (ES3+)
EqualityExpression !== RelationalExpression (ES3+)
Unambiguously and in no uncertain terms, the following is a completely
valid expression (ie. will not throw a SyntaxError exception):
100 % 1 1e1 0xff - 5 + (+5) 10 1.5 - 1..toString() === (function()
{}()) !== parseInt(1, 10) * 1 | 0 1;
// 1
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
questions or previously unclear points.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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 questions or previously unclear points. You seem to be stating that once something's been published for a while, it's frozen. In reality, only the web-exposed parts are, and then only the parts that the web actually depends on. We can potentially change *everything else*. Thinking anything else is harmful, as it means you avoid thinking about possible good ideas just because you've arbitrarily ruled out certain classes of changes, despite there being no reason to avoid that change. Standards exist for the sole purpose of helping interoperability, which we like because it makes it easier to do cool things. Don't put them on a pedestal they don't deserve. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
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) {
for(var i=1; iargs.length; i++) {
if (!op( args[i-1], args[i])) return false;
}
return true;
}
console.log( sortedBy( (a,b)=ab, 2,3,4) ); // true
console.log( sortedBy( (a,b)=ab, 2,4,3) ); // false
console.log( sortedBy( (a,b)=ab, 2,2,3) ); // false
console.log( sortedBy( (a,b)=a=b, 2,2,3) ); // true
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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 using `new` should always return an object from the builtins, ergo Symbols objects (whether wrappers or not) should be usable (either through auto-unwrapping or no primitive form) or some inconsistency or another will be introduced. Allen's proposal from March, for Symbol and (I think) all scalar value objects, would be for new to throw. Vector and struct value objects would be mutable if new'ed, immutable copy-semantics value otherwise. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
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
them makes me want to use `new` with that factory. But using `new` should
always return an object from the builtins, ergo Symbols objects (whether
wrappers or not) should be usable (either through auto-unwrapping or no
primitive form) or some inconsistency or another will be introduced.
Allen's proposal from March, for Symbol and (I think) all scalar value
objects, would be for new to throw.
No, that wasn't what I was trying to say in March. I was saying that if
symbols were going to be non-object primitive values without a corresponding
wrapper class and 'Symbol( )') was a function that produced such values, then
'new Symbol( )' should throw because because 'new' is the object creation
operator and there would be no such objects to create.
On the other hand if symbols were exotic objects then 'new Symbols( )' would be
the natural way to create them. We might choose to also let 'Symbol( )' act as
a factory function for creating symbols even though I argue that using
constructors as callable factories should be an ES6 anti-pattern.
If symbol are primitive values with a corresponding Symbol wrapper class
(Andreas' preference) then for consistency with Number/String/Boolean 'new
Symbol(sym)' assuming 'sym' is a primitive symbol value should create a wrapper
object for 'sym'. Probably we would choose to make 'Symbol()' be a generator
(normal English usage, not funciton*) of symbol values. That, however, is
somewhat of a departure from the meaning of 'Number()', 'String()', or
'Boolean()' each of which returns a specific value (0, , false) rather than
generating new unique values
For, symbols I argue that the second alternative is the least anomalous because
it threats symbols almost exactly as if defined as:
class Symbol extends null {
static [@@create] () {
return Object.freeze( %tagAsSymbol({__proto__: null}));
}
constructor() {
if (!%hasSymbolTag(this)) return new Symbol();
}
}
Maybe this analysis can be extended to other value objects. I'm in the 'new'
is the preferred way to create objects camp. However, applying the same logic
used for symbols is not all that straightforward. Consider if you are
implementing such a class in ES, for example (very rough):
class BigNum extends ValueObject {
constructor (value) {
setPrivateState(this, new DigitVector(value)); //assume that DigitVector
handles various numeric/sting types (including DigitVectors) as arguments
}
...
plusOperator (rhs) {
return new BigNum(getPrivateState(this).addDigits(getPrivateState(rhs));
}
...
}
You still need a way to instantiate the internal state that represents the
value.
Vector and struct value objects would be mutable if new'ed, immutable
copy-semantics value otherwise.
I don't know,
'new Foo(args)' create a mutable Foo object
'Foo(args)' create an immutable Foo object
isn't an idiom that we've had before
Allen
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
