Re: Frozen Date objects?
On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Jul 17, 2013, at 16:59 , Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote: On 7/17/2013 4:54 PM, Norbert Lindenberg wrote: On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote: On 7/17/2013 4:42 PM, Brandon Benvie wrote: On 7/17/2013 4:36 PM, Jonas Sicking wrote: Is this simply a SpiderMonkey bug? Do we expect JS code to be able to handle Date objects representing timezones other than the user's current timezone? What happens if the timezone changes between the creation of two Date objects, such as for daylight savings or the user changes their system timezone? Having just tested this, it is possible in SM to get two Dates that report different values from getTimezoneOffset. How? Norbert Create a Date object, change the system timezone, create a second Date object. They reflect the timezone at time of Date object creation, not a static one. That doesn't reflect what I'm seeing. I see the timezone of all Date objects changing whenever the timezone is update. Existing instances are also changed. Seeing getTimezoneOffset change for *all* Date objects is what I expect because none of them actually *have* a time zone - getTimezoneOffset uses the one local time zone that the JavaScript engine maintains somewhere. I still don't feel like I have a clear answer to two fundamental questions when designing DOM specs: 1. Is it ever appropriate to return Date objects from methods in the DOM? If so, in what circumstances. Two cases where we are currently considering using Date objects are: * When the event related to a Notification [1] happened, or is set to happen. What we need here is a timezone-less timestamp. * When expressing when a scheduled task [2] is set to fire. The task is set to fire at a designated point in time. I.e. a timezone-less timestamp. Though in the future it would be nice to support scheduled tasks that are set to happen in a particular time+timezone. 2. Is it ever appropriate to return a Date object from a readonly property. This seems like a bad idea if we can't freeze it since it would mean that if someone modifies the Date object, all other consumers would see a changed date, and the property wouldn't really be readonly. We could return a new Date instance each time the getter is run, but that would mean that x.prop !== x.prop which seems surprising. However this thread does seem to make it clear that it is inappropriate to design an API which accepts Date objects as input, if that API wants to enable the caller to provide a time+timezone. This since it is not possible to create Date objects for arbitrary timezones, but rather only for the users current timezone. So a caller couldn't specify timezone. Possibly this will be remedied in the future. But for APIs that are shipping in the near future, this limitation seems to exist. Such an API could instead separate the timestamp and timezone inputs. Potentially the timestamp part could use a Date object. Again, it's unclear if using a Date object to represent the timestamp would be appropriate. A concrete example here is the create-new-scheduled-task API in [3]. If we wanted to expand this API to support specifying a timezone in addition to the timestamp, we would have to add a separate argument, rather than simply relying on Date objects. And possibly we should stop using Date objects entirely, even if we don't want timezone support. [1] http://notifications.spec.whatwg.org/#notification [2] http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask [3] http://www.w3.org/2012/sysapps/web-alarms/#taskscheduler / Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
On Mon, Jul 22, 2013 at 5:25 AM, Brendan Eich bren...@mozilla.com wrote: This is the part we can't determine. The web is not just the Google-indexable (by what user agent?) part, but paywalled and intranet content as well. I've written before that finding true positives helps reject a proposed incompatible change, but finding no positives does not prove that we can make the change. Furthermore, the first browser to roll the dice and face breakage loses, making implementors generally unwilling to take even likely-small risks. This browser Prisoner's Dilemma can be helped by cooperation, e.g., among TC39ers, but even then only for a big enough payoff. See the typeof null == null attempt early in ES6 development for an example. typeof null == null is a different case though. typeof is a requirement for checking the existence of pre-declared variables, so you could expect something like, if (typeof someVar === object someVar === null), to appear at least in a few places on the web. Tab's saying that this proposal wouldn't break much (if anything) because code isn't written like this anywhere: it wouldn't be readable or reliable. Writing a b c in ES=5 would be either stupidity or ignorance (in the case of the latter then this proposal would probably fix more code than it breaks). For equality, there might be a problem where code is written like, if (a === b === true), where a and b are something other than booleans. I could maybe see an outside chance that this appears somewhere on the web or an intranet, but maybe there's a way we can deal with it so it doesn't break backwards compatibility. use chained comparisons;, anyone? ;-) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
* Andy Earnshaw wrote: typeof null == null is a different case though. typeof is a requirement for checking the existence of pre-declared variables, so you could expect something like, if (typeof someVar === object someVar === null), to appear at least in a few places on the web. Tab's saying that this proposal wouldn't break much (if anything) because code isn't written like this anywhere: it wouldn't be readable or reliable. Writing a b c in ES=5 would be either stupidity or ignorance (in the case of the latter then this proposal would probably fix more code than it breaks). If that code is interpreted reliably and the behavior is desired, there is no reason to assume that e.g. code obfuscators would not produce it. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Two (or three) remarks: (1) The following expressions are perfectly reasonable, where a, b, c, d are variables holding numbers, and y is a variable (not a literal) holding a boolean: a b == y a b == c d and even (although it demands some imagination): a b = y where x = y is a hackish way to express the so-called material implication (x → y) as defined in: http://en.wikipedia.org/wiki/Boolean_algebra#Derived_operations Even if we ignore the last expression, it would be surprising (for, e.g., people used to Python), if we change the meaning of `a b = y` but not the one of `a b == c d`, so we are probably bound to change the meaning of very reasonable expressions anyway. (2) If we change the meaning of `a b c`, then someone will use var a = 1, b = 2, c = 3; a b c; // true in newer browsers, then check var a = 1, b = 2, c = 3; a b c; // true in older browsers, and will fail to notice that their code is broken. In order to mitigate that hazard (supposing we want to make the breaking change anyway), we may want to invalidate expressions like `a b c` in ES6 (throwing a Syntax Error) and redefine their meaning in ES7. use chained comparisons;, anyone? ;-) (3) Instead of a use chained comparisons directive, I dream of an implicit use perfect language directive, where (1) typeof null === null, (2) wrapper objects around primitives do not exist, (3) chained comparisons are implemented, (4) Date objects are not Y2K-broken by design, (5) Date objects are compared by value, (6) concatenation and addition are not conflated into one operator, (7) I am able to make coffee from within my preferred browser. :-) —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Jul 21, 2013, at 11:05 PM, Jonas Sicking wrote: I still don't feel like I have a clear answer to two fundamental questions when designing DOM specs: 1. Is it ever appropriate to return Date objects from methods in the DOM? If so, in what circumstances. Two cases where we are currently considering using Date objects are: ... 2. Is it ever appropriate to return a Date object from a readonly property. How about : 3. Is it ever appropriate for a DOM API to accept and retain a reference to a Date object? The timevalue of a Date object that was passed to a DOM API can be modified by the original client after the DOM call returns. If the DOM has retained and uses a reference to the Date object it will see the modified timevalue rather than the originally pass timevalue. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Chained comparisons from Python and CoffeeScript
From: Andy Earnshaw [andyearns...@gmail.com] if pragmas are to be entered into the specification They are not. then it could even become part of use strict; Or even better: it could become part of `./andys-transpiler myfile.andy`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Mon, Jul 22, 2013 at 7:07 AM, Mark S. Miller erig...@google.com wrote: For *all* of these, what benefits to Date objects provide over just using numbers? That is indeed the question. I think we attempted to use Date objects in an effort to be more javascripty and less DOM doing it's own thing. But this thread is leading me to believe that using Date objects in the DOM is possibly never appropriate. / Jonas On Sun, Jul 21, 2013 at 11:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 17, 2013 at 5:11 PM, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote: On Jul 17, 2013, at 16:59 , Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie bben...@mozilla.com wrote: On 7/17/2013 4:54 PM, Norbert Lindenberg wrote: On Jul 17, 2013, at 16:51 , Brandon Benvie bben...@mozilla.com wrote: On 7/17/2013 4:42 PM, Brandon Benvie wrote: On 7/17/2013 4:36 PM, Jonas Sicking wrote: Is this simply a SpiderMonkey bug? Do we expect JS code to be able to handle Date objects representing timezones other than the user's current timezone? What happens if the timezone changes between the creation of two Date objects, such as for daylight savings or the user changes their system timezone? Having just tested this, it is possible in SM to get two Dates that report different values from getTimezoneOffset. How? Norbert Create a Date object, change the system timezone, create a second Date object. They reflect the timezone at time of Date object creation, not a static one. That doesn't reflect what I'm seeing. I see the timezone of all Date objects changing whenever the timezone is update. Existing instances are also changed. Seeing getTimezoneOffset change for *all* Date objects is what I expect because none of them actually *have* a time zone - getTimezoneOffset uses the one local time zone that the JavaScript engine maintains somewhere. I still don't feel like I have a clear answer to two fundamental questions when designing DOM specs: 1. Is it ever appropriate to return Date objects from methods in the DOM? If so, in what circumstances. Two cases where we are currently considering using Date objects are: * When the event related to a Notification [1] happened, or is set to happen. What we need here is a timezone-less timestamp. * When expressing when a scheduled task [2] is set to fire. The task is set to fire at a designated point in time. I.e. a timezone-less timestamp. Though in the future it would be nice to support scheduled tasks that are set to happen in a particular time+timezone. 2. Is it ever appropriate to return a Date object from a readonly property. This seems like a bad idea if we can't freeze it since it would mean that if someone modifies the Date object, all other consumers would see a changed date, and the property wouldn't really be readonly. We could return a new Date instance each time the getter is run, but that would mean that x.prop !== x.prop which seems surprising. However this thread does seem to make it clear that it is inappropriate to design an API which accepts Date objects as input, if that API wants to enable the caller to provide a time+timezone. This since it is not possible to create Date objects for arbitrary timezones, but rather only for the users current timezone. So a caller couldn't specify timezone. Possibly this will be remedied in the future. But for APIs that are shipping in the near future, this limitation seems to exist. Such an API could instead separate the timestamp and timezone inputs. Potentially the timestamp part could use a Date object. Again, it's unclear if using a Date object to represent the timestamp would be appropriate. A concrete example here is the create-new-scheduled-task API in [3]. If we wanted to expand this API to support specifying a timezone in addition to the timestamp, we would have to add a separate argument, rather than simply relying on Date objects. And possibly we should stop using Date objects entirely, even if we don't want timezone support. [1] http://notifications.spec.whatwg.org/#notification [2] http://www.w3.org/2012/sysapps/web-alarms/#interface-scheduledtask [3] http://www.w3.org/2012/sysapps/web-alarms/#taskscheduler / Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 21, 2013, at 11:05 PM, Jonas Sicking wrote: I still don't feel like I have a clear answer to two fundamental questions when designing DOM specs: 1. Is it ever appropriate to return Date objects from methods in the DOM? If so, in what circumstances. Two cases where we are currently considering using Date objects are: ... 2. Is it ever appropriate to return a Date object from a readonly property. How about : 3. Is it ever appropriate for a DOM API to accept and retain a reference to a Date object? We could even generalize it to: 3. Is it ever appropriate for a DOM API to accept a reference to a Date object. Even if we just take a snapshot of the value returned by .getTime() and retain that snapshot, is that really beneficial to taking a numeric timestamp? The feedback in this thread seems to indicate no on all three? / Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eich bren...@mozilla.com wrote: Tab Atkins Jr. wrote: In reality, only the web-exposed parts are, What is not web-exposed here, pray tell? The parser itself. Only the results of the parser are, in terms of observable program behavior and presence/absence of syntax errors. and then only the parts that the web actually depends on. This is the part we can't determine. The web is not just the Google-indexable (by what user agent?) part, but paywalled and intranet content as well. I've written before that finding true positives helps reject a proposed incompatible change, but finding no positives does not prove that we can make the change. Furthermore, the first browser to roll the dice and face breakage loses, making implementors generally unwilling to take even likely-small risks. This browser Prisoner's Dilemma can be helped by cooperation, e.g., among TC39ers, but even then only for a big enough payoff. See the typeof null == null attempt early in ES6 development for an example. Preaching to the choir, buddy - I've been standardsing for quite a while too. I'm not stating an opinion either way on whether this change would be possible, I'm just pushing back on Rick's incorrect statements about the primacy of an existing standard. Gotta keep good brain hygiene, you know. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Le 22 juil. 2013 à 17:55, Andy Earnshaw andyearns...@gmail.com a écrit : On Mon, Jul 22, 2013 at 2:24 PM, Claude Pache claude.pa...@gmail.com wrote: Even if we ignore the last expression, it would be surprising (for, e.g., people used to Python), if we change the meaning of `a b = y` but not the one of `a b == c d`, so we are probably bound to change the meaning of very reasonable expressions anyway. Well, as Tab pointed out, comparison operators have the same precedence in Python, whereas in JavaScript the equality operators have a lower precedence. So a b == c d is the same as (a b) == (c d). Only operators with the same precedence could be chained, where's the confusion in that? Python users still have to learn the same stuff when writing JavaScript. In the three languages you have cited (Python, Perl6 and CoffeeScript), all comparison operators (both equality and inequality ones) can be chained together. Introducing only half-baked chaining in ES will be quite confusing. If we dare introduce chaining, which is already a disruptive change, we ought to go until the end and to adjust the precedence of relational and equality operators as well. (Actually, we would introduce an n-ary comparison operator.) —Claude___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote: On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 3. Is it ever appropriate for a DOM API to accept and retain a reference to a Date object? We could even generalize it to: 3. Is it ever appropriate for a DOM API to accept a reference to a Date object. Even if we just take a snapshot of the value returned by .getTime() and retain that snapshot, is that really beneficial to taking a numeric timestamp? The feedback in this thread seems to indicate no on all three? However, just like you you guys trying to define DOM APIs, many JavaScript programmers will not be aware of these subtleties and expect to be able to use Date objects with these APIs. I would suggest, the following conventions: 1) APIs should accept Date objects as inputs, but when doing do so they should only retain and use the timevalue wrapped by the date object. 2) APIs may return Date objects but they should always be newly created instances and never retain references to them. An API client might mutate such returned Date objects but that's really the clients business and it will have no impact upon the DOM. In addition, for APIs that take dates as input might consider accepting both Date objects and Numbers that are interpreted as timevalues. That should probably be a design decision that is consistently applied to all DOM APIS. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote: On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 3. Is it ever appropriate for a DOM API to accept and retain a reference to a Date object? We could even generalize it to: 3. Is it ever appropriate for a DOM API to accept a reference to a Date object. Even if we just take a snapshot of the value returned by .getTime() and retain that snapshot, is that really beneficial to taking a numeric timestamp? The feedback in this thread seems to indicate no on all three? However, just like you you guys trying to define DOM APIs, many JavaScript programmers will not be aware of these subtleties and expect to be able to use Date objects with these APIs. I would suggest, the following conventions: 1) APIs should accept Date objects as inputs, but when doing do so they should only retain and use the timevalue wrapped by the date object. Makes sense. And in fact, like Dominic points out, that will simply follow automatically when accepting a numeric timestamp since WebIDL will always use ToNumber to coerce any passed in value to a number. 2) APIs may return Date objects but they should always be newly created instances and never retain references to them. An API client might mutate such returned Date objects but that's really the clients business and it will have no impact upon the DOM. The emails in this thread seems to indicate that we should in fact not return Date objects ever (though like any rule, I could imagine there being exceptions). Instead we should simply return numeric timestamps. However, we should of course expect other APIs, such as ones in JS libraries, will use Date objects. The best ways to deal with that is through your rule 1) above. I.e. accepting Date objects in addition to numeric timestamps in input. / Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
On Monday, July 22, 2013, Jonas Sicking wrote: On Mon, Jul 22, 2013 at 10:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com javascript:; wrote: On Jul 22, 2013, at 9:42 AM, Jonas Sicking wrote: On Mon, Jul 22, 2013 at 7:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com javascript:; wrote: 3. Is it ever appropriate for a DOM API to accept and retain a reference to a Date object? We could even generalize it to: 3. Is it ever appropriate for a DOM API to accept a reference to a Date object. Even if we just take a snapshot of the value returned by .getTime() and retain that snapshot, is that really beneficial to taking a numeric timestamp? The feedback in this thread seems to indicate no on all three? However, just like you you guys trying to define DOM APIs, many JavaScript programmers will not be aware of these subtleties and expect to be able to use Date objects with these APIs. I would suggest, the following conventions: 1) APIs should accept Date objects as inputs, but when doing do so they should only retain and use the timevalue wrapped by the date object. Makes sense. And in fact, like Dominic points out, that will simply follow automatically when accepting a numeric timestamp since WebIDL will always use ToNumber to coerce any passed in value to a number. 2) APIs may return Date objects but they should always be newly created instances and never retain references to them. An API client might mutate such returned Date objects but that's really the clients business and it will have no impact upon the DOM. The emails in this thread seems to indicate that we should in fact not return Date objects ever (though like any rule, I could imagine there being exceptions). Instead we should simply return numeric timestamps. However, we should of course expect other APIs, such as ones in JS libraries, will use Date objects. The best ways to deal with that is through your rule 1) above. I.e. accepting Date objects in addition to numeric timestamps in input. Yes, just as I said very early on in this thread (with regard to returned values). Is it possible to retroactively apply Allen's recommendation to existing APIs that accept one or the other, allowing them to accept both as the same? Is it worth doing so (it may not be)? Rick / Jonas ___ es-discuss mailing list es-discuss@mozilla.org javascript:; https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Tab Atkins Jr. wrote: On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eichbren...@mozilla.com wrote: Tab Atkins Jr. wrote: In reality, only the web-exposed parts are, What is not web-exposed here, pray tell? The parser itself. Only the results of the parser are, in terms of observable program behavior and presence/absence of syntax errors. This is irrelevant, since the change you are proposing is a compatibility-breaking one, even though parse trees are not yet reflectable. and then only the parts that the web actually depends on. This is the part we can't determine. The web is not just the Google-indexable (by what user agent?) part, but paywalled and intranet content as well. I've written before that finding true positives helps reject a proposed incompatible change, but finding no positives does not prove that we can make the change. Furthermore, the first browser to roll the dice and face breakage loses, making implementors generally unwilling to take even likely-small risks. This browser Prisoner's Dilemma can be helped by cooperation, e.g., among TC39ers, but even then only for a big enough payoff. See the typeof null == null attempt early in ES6 development for an example. Preaching to the choir, buddy - I've been standardsing for quite a while too. So why were you preaching at Rick? I didn't want to reply, but at some point the one-sided arguing got to be too much. Look, you're proposing an incompatible change, akin to typeof null's result change. It doesn't matter why people might write code you'd break, it matters how much code exists. That's an empirical question. Exhorting people here does nothing but annoy some of us. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Claude Pache wrote: (Actually, we would introduce an n-ary comparison operator.) Sounds like a function ;-). Did you have straw syntax in mind? This reminds me (not the n-ary part, but the new operator bit)... We could also introduce binary =, AKA cmp, return -1, 0, or 1. Imagine the sort fun: a.sort((a, b) = a = b) :-P. The win over using a.sort((a, b) = a - b) is that = would work as expected for string-typed a and b as well. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
On Mon, Jul 22, 2013 at 12:42 PM, Brendan Eich bren...@mozilla.com wrote: Tab Atkins Jr. wrote: On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eichbren...@mozilla.com wrote: Tab Atkins Jr. wrote: In reality, only the web-exposed parts are, What is not web-exposed here, pray tell? The parser itself. Only the results of the parser are, in terms of observable program behavior and presence/absence of syntax errors. This is irrelevant, since the change you are proposing is a compatibility-breaking one, even though parse trees are not yet reflectable. Of course. But Rick's argument against was justifying itself on the parser, not expectation of web-dependence on the results. Just trying to point out the correct thing to be arguing about. and then only the parts that the web actually depends on. This is the part we can't determine. The web is not just the Google-indexable (by what user agent?) part, but paywalled and intranet content as well. I've written before that finding true positives helps reject a proposed incompatible change, but finding no positives does not prove that we can make the change. Furthermore, the first browser to roll the dice and face breakage loses, making implementors generally unwilling to take even likely-small risks. This browser Prisoner's Dilemma can be helped by cooperation, e.g., among TC39ers, but even then only for a big enough payoff. See the typeof null == null attempt early in ES6 development for an example. Preaching to the choir, buddy - I've been standardsing for quite a while too. So why were you preaching at Rick? I didn't want to reply, but at some point the one-sided arguing got to be too much. Look, you're proposing an incompatible change, akin to typeof null's result change. It doesn't matter why people might write code you'd break, it matters how much code exists. That's an empirical question. Exhorting people here does nothing but annoy some of us. You've lost track of who's suggesting what. I'm not suggesting anything - it was a proposal by Andy. I've brought up problems with the suggestion in the thread. This side-thread is about the fact that Rick shot down the idea not based on possible breakage, but on a pure this would be a spec change argument, which is not a valid argument in and of itself against a change. (It points to the possibility of web-compat issues which would prevent the change, but does not itself prevent anything.) I just wanted to avoid letting a precedent stand of something being rejected purely on spec-conflict grounds. I didn't intend for the point to get confused like this. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
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
Relax mutable in the first comment and remove object from the second
comment and we have relevant precedent:
new Boolean(false) // create an extensible wrapper object
Boolean(false) // unobservably return false or create a new false
new Number(42) // create an extensible wrapper object
Number(42) // unobservably return the argument or create a new 42
new String('hi') // create an extensible wrapper object
String('hi') // unobservably return argument or create new 'hi'
Except that:
new Boolean(false) === false //false similarly String and Number
Boolean(false) === false //truesimilarly String and Number
so the difference between wrappers and primitive values is observable. It
isn't observable whether there is a single or multiple heap element for each
logically === equivalent primitive value/
The point about value objects to attend to here: their identity based on
frozen contents.
(Why are they objects? Because everything's an object except for the legacy
primitives.)
The truthiness of new Boolean(false) is a problem for numeric value objects,
which my int64/uint64 prototype addresses by including boolean test among the
operators that can be defined for value objects.
There's no perfect precedent. Falsy 'new Boolean(false)' was rejected in ES1
standardization because it implied a conversion from object to boolean, which
might happen more than once for a given sub-expression due to || and being
value-preserving.
I think the truthiness of 'new Boolean(false)' is a one-off special case that
we shouldn't worry about as a precedent. I don't believe there are equivalent
issues with String or Number.
What's more important given JS's legacy than precedent: serving users by
considering use-cases for value objects.
The use-case for mutable structs and vectors is clear from today's objects
used for points, homogenous coordinates, rectangles, shapes, etc.
The use-case for immutable structs and vectors is clear from SIMD work under
way in TC39, in JS extensions, in Dart.
The propose to serve both use-cases by specifying that 'new T(x)' constructs
a mutable value object while calling 'T(x)' makes an immutable one aims to
avoid clumsy alternative static method factories or differently named
wrappers.
This would be a new idiom, and one that wouldn't necessarily apply to
non-structured objects. This is a refactoring hazard if someone starts with a
normal object and decides to re-implement as a struct-based object.
Since this is a new idiom, other new idioms could be considered. For example:
new T(x) //create a mutable instance:
T.value(x) //create an immutable instance
bikesheding starts here...
Debatable, but showing class BigNum extends ValueObject doesn't decide the
question. We are introducing new semantics, starting with by-value identity
rather than by-reference, and extending to operators and literals. We can't
do this just using ES6 'class' syntax as-is.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Tab Atkins Jr. wrote: Of course. But Rick's argument against was justifying itself on the parser, not expectation of web-dependence on the results. It was clear enough (to me and I think others) that Rick was talking indirectly about web-dependence, but let's not get stuck here. You've lost track of who's suggesting what. I'm not suggesting anything - it was a proposal by Andy. Somehow I thought you were on board (you *are* a Pythonista :-P) -- sorry. While I have you (and others here), I wish we had a code search engine strong enough to find patterns such as x y z and the like on the web. Anyone know of anything like that? I've brought up problems with the suggestion in the thread. This side-thread is about the fact that Rick shot down the idea not based on possible breakage, but on a pure this would be a spec change argument, which is not a valid argument in and of itself against a change. (It points to the possibility of web-compat issues which would prevent the change, but does not itself prevent anything.) You are misreading Rick. When you think someone is making a dumb point, try reading them a bit harder for meaning. I just wanted to avoid letting a precedent stand of something being rejected purely on spec-conflict grounds. I didn't intend for the point to get confused like this. No one here was confused, as far as I can tell. There were too many words and bruised feelings, though :-|. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen Wirfs-Brock wrote:
On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
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
Relax mutable in the first comment and remove object from the second
comment and we have relevant precedent:
new Boolean(false) // create an extensible wrapper object
Boolean(false) // unobservably return false or create a new false
new Number(42) // create an extensible wrapper object
Number(42) // unobservably return the argument or create a new 42
new String('hi') // create an extensible wrapper object
String('hi') // unobservably return argument or create new 'hi'
Except that:
new Boolean(false) === false //false similarly String and Number
Boolean(false) === false //truesimilarly String and Number
so the difference between wrappers and primitive values is observable.
Sure, legacy crap we must not copy into new types. Right?
It isn't observable whether there is a single or multiple heap element for
each logically === equivalent primitive value/
I explicitly addressed truthy ToObject later. Did you miss it? Boolean
is a terrible precedent for value objects, which must include 0 when
numeric (int64, uint64, bignum, decimal, rational, etc.).
The point about value objects to attend to here: their identity based on frozen
contents.
(Why are they objects? Because everything's an object except for the legacy
primitives.)
The truthiness of new Boolean(false) is a problem for numeric value objects,
which my int64/uint64 prototype addresses by including boolean test among the
operators that can be defined for value objects.
There's no perfect precedent. Falsy 'new Boolean(false)' was rejected in ES1
standardization because it implied a conversion from object to boolean, which might
happen more than once for a given sub-expression due to || and being
value-preserving.
I think the truthiness of 'new Boolean(false)' is a one-off special case that
we shouldn't worry about as a precedent. I don't believe there are equivalent
issues with String or Number.
Sure: is falsy but new String() is truthy; 0 and NaN are falsy but
new Number(0), e.g., is truthy.
Ok, so a three-off special case-set we should not imitate with value
objects in general. Right?
What's more important given JS's legacy than precedent: serving users by
considering use-cases for value objects.
The use-case for mutable structs and vectors is clear from today's objects used
for points, homogenous coordinates, rectangles, shapes, etc.
The use-case for immutable structs and vectors is clear from SIMD work under
way in TC39, in JS extensions, in Dart.
The propose to serve both use-cases by specifying that 'new T(x)' constructs a
mutable value object while calling 'T(x)' makes an immutable one aims to avoid
clumsy alternative static method factories or differently named wrappers.
This would be a new idiom, and one that wouldn't necessarily apply to
non-structured objects. This is a refactoring hazard if someone starts with a
normal object and decides to re-implement as a struct-based object.
If you are arguing that constructors must not do something other than
construct when called, let's have that discussion separately. It's a
general fly in your refactoring ointment -- and has been forever in JS.
Since this is a new idiom, other new idioms could be considered. For example:
new T(x) //create a mutable instance:
T.value(x) //create an immutable instance
bikesheding starts here...
I thought about such things but it's not only a matter of bikeshedding.
Usability comes first and is not all about aeshetics. Say we add int64.
To convert to it, must I call
int64.value(x)
and not
int64(x)
merely to preserve some object-idiom idiocy that no one wants for int64,
namely:
new int64(x) // throws, does not make a mutable object
?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
* Brendan Eich wrote:
We could also introduce binary =, AKA cmp, return -1, 0, or 1.
Imagine the sort fun:
a.sort((a, b) = a = b)
:-P. The win over using
a.sort((a, b) = a - b)
is that = would work as expected for string-typed a and b as well.
In Perl = compares as if the operands had been converted to numbers
and the cmp operator as if the operands had been converted to strings.
If you are suggesting to have `=` change behavior based on type in-
spection at runtime, that behavior might lead to subtle bugs when the
array contains strings and numbers (e.g., you might expect swapping
the operands is the same as reversing the result, but it might not be.
Indeed, without specifying the exact sorting algorithm you might get
different sort orders in different implementations due to differences
in which values are compared in which order). Having two operators a-
voids that.
The other day I published http://search.cpan.org/dist/List-OrderBy/
which takes a lesson from .NET and offers better syntax for multi-key
sorts, `my @sorted = order_by { ... } then_by { ... } @unsorted;`. I
ended up with a not-so-nice list of variants to support ascending and
descending order and numeric and string comparisons. Thinking about
that now makes me wonder if the Voyager holodeck has and requires an
Arch console for advanced uses. In Haskell you would never write code
like `a.sort((a, b) = a = b)` as, to paraphrase, `a.sort(=)` is
much more clear.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
On Mon, Jul 22, 2013 at 3:19 PM, Brendan Eich bren...@mozilla.com wrote: Tab Atkins Jr. wrote: Of course. But Rick's argument against was justifying itself on the parser, not expectation of web-dependence on the results. It was clear enough (to me and I think others) that Rick was talking indirectly about web-dependence, but let's not get stuck here. If so, then cool, we can all drop that sub-thread. ^_^ You've lost track of who's suggesting what. I'm not suggesting anything - it was a proposal by Andy. Somehow I thought you were on board (you *are* a Pythonista :-P) -- sorry. Oh, I'm on board with the idea - I like the Python functionality, and have found it very useful in avoiding temporary variables just to check that a value is within a particular range. But I think there's a small but reasonable chance this would be web-breaking, and wouldn't push it unless someone with more power inside a browser is willing to push on this. (I'm merely a spec-writer.) Also, I'm quite certain that changing the precedence of the equality and the comparison ops would be web-breaking, as I've used that fact before (specifically, comparing the result of two comparisons directly, as given in an example by Andy). I might be okay with just allowing chaining of same-precedence things, but it would be weird and different from the other languages that have this functionality. While I have you (and others here), I wish we had a code search engine strong enough to find patterns such as x y z and the like on the web. Anyone know of anything like that? Now that Google's Code Search is dead, I'm not aware of a good one. :/ ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Bjoern Hoehrmann wrote:
* Brendan Eich wrote:
We could also introduce binary=, AKA cmp, return -1, 0, or 1.
Imagine the sort fun:
a.sort((a, b) = a= b)
:-P. The win over using
a.sort((a, b) = a - b)
is that= would work as expected for string-typed a and b as well.
In Perl= compares as if the operands had been converted to numbers
and the cmp operator as if the operands had been converted to strings.
If you are suggesting to have `=` change behavior based on type in-
spection at runtime, that behavior might lead to subtle bugs when the
array contains strings and numbers (e.g., you might expect swapping
the operands is the same as reversing the result, but it might not be.
Indeed, without specifying the exact sorting algorithm you might get
different sort orders in different implementations due to differences
in which values are compared in which order). Having two operators a-
voids that.
Good point, I'd forgotten my Perl (what little I had ;-).
The other day I published http://search.cpan.org/dist/List-OrderBy/
which takes a lesson from .NET and offers better syntax for multi-key
sorts, `my @sorted = order_by { ... } then_by { ... } @unsorted;`. I
ended up with a not-so-nice list of variants to support ascending and
descending order and numeric and string comparisons. Thinking about
that now makes me wonder if the Voyager holodeck has and requires an
Arch console for advanced uses. In Haskell you would never write code
like `a.sort((a, b) = a= b)` as, to paraphrase, `a.sort(=)` is
much more clear.
Yes, that's what I wanted to suggest, but I couldn't sell in operand
position (to use operator-precedence parsing -- shades of E4X).
Operators as first-class functions are on the radar for value objects,
but not yet proposed with this kind of syntax.
Thanks for setting me straight on cmp vs. =.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
Jonas Sicking wrote: 2) APIs may return Date objects but they should always be newly created instances and never retain references to them. An API client might mutate such returned Date objects but that's really the clients business and it will have no impact upon the DOM. The emails in this thread seems to indicate that we should in fact not return Date objects ever (though like any rule, I could imagine there being exceptions). Instead we should simply return numeric timestamps. Yup. Dave has a sad history. Cloned from JDK1.0 java.util.Date, y2k-bugs and all, with hidden mutable state, it still vexes. On top of the legacy smell, the question arises: why create an object with mutable state when you are expressing a universal time coordinate? A number wins in almost all cases, for economy and precision, if not economy of expression for code that will (somewhere) use the timestamp to create a Date object to present some strings to a user. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
Brendan Eich wrote: Dave has a sad history LOL! *Date*, not Dave. Dave has a great history (I know many Daves). /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 22, 2013, at 3:25 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: On Jul 20, 2013, at 4:14 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: right, to all of the above. This would be a new idiom, and one that wouldn't necessarily apply to non-structured objects. This is a refactoring hazard if someone starts with a normal object and decides to re-implement as a struct-based object. If you are arguing that constructors must not do something other than construct when called, let's have that discussion separately. It's a general fly in your refactoring ointment -- and has been forever in JS. Yes, I agree that is a separate discussion. We already have constructors that do different things and it remains possible to define them using ES6 class declarations regardless of whether or not it ends up being considered a pattern or an anti=pattern. Since this is a new idiom, other new idioms could be considered. For example: new T(x) //create a mutable instance: T.value(x) //create an immutable instance bikesheding starts here... I thought about such things but it's not only a matter of bikeshedding. Usability comes first and is not all about aeshetics. Say we add int64. To convert to it, must I call int64.value(x) and not int64(x) merely to preserve some object-idiom idiocy that no one wants for int64, namely: new int64(x) // throws, does not make a mutable object My concern is that the pattern new T(x) //create a mutable instance: T(x) //create an immutable instance is a new one that we really don't reflect current usage in either the specification or in the wild, eg RegExp, Date. Also Map/Set as currently implemented in FF, but that is also a seperate (but related) discussion. I agree that int64(x) is nice for int64 (although I would expect such scalar values to me immutable regardless of how you create them). It is also appealing for structs but not necessarily for objects which means it is hard to know when you see 'new Foo(x)' vs 'Foo(x)' whether the mutable/immutable pattern applies or not for Foo. Presumably Structs are subclassable. But, where I see the real problem is if we wanted to support class declarations that use Structs as their private state. We would still want such classes to be subclassable and super calls of the constructor would still be needed for initialize both mutable and immutable subclasses. It seems like the real usability challenge is finding a scheme that is pleasant for both scalars and potentially subclass able objects. Here another stab at the int64 use case. let int64 = (...args) = Object.freeze(new Builtins.Int64(...args)); // int64 is a non-constructable function. It is the normal way of creating Int64 instances // Builtins.Int64 is (at least conceptually) a normal constructor that uses 'new' to create instances but would seldom be directly used in that manner // For Int64 the Object.freeze may actually be redundant but wouldn't necessarily be so if the pattern was extended to structured data. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen Wirfs-Brock wrote: My concern is that the pattern new T(x) //create a mutable instance: T(x) //create an immutable instance is a new one that we really don't reflect current usage in either the specification or in the wild, eg RegExp, Date. Those are definitely not value objects. More's the pity, perhaps, but too late. Also Map/Set as currently implemented in FF, but that is also a seperate (but related) discussion. Definitely not value objects. I agree that int64(x) is nice for int64 (although I would expect such scalar values to me immutable regardless of how you create them). The intuition (supported by other languages) is that 'new' heap-allocates something mutable by default. Stack allocation and (implicit or not) coercion does not. C++ is not far from the mark here, but IIRC C# is similar. It is also appealing for structs but not necessarily for objects which means it is hard to know when you see 'new Foo(x)' vs 'Foo(x)' whether the mutable/immutable pattern applies or not for Foo. Indeed, structs are new in this sense. I don't think T.value(x) helps, though. Presumably Structs are subclassable. But, where I see the real problem is if we wanted to support class declarations that use Structs as their private state. We would still want such classes to be subclassable and super calls of the constructor would still be needed for initialize both mutable and immutable subclasses. That's a challenge to rise to ;-). It seems like the real usability challenge is finding a scheme that is pleasant for both scalars and potentially subclass able objects. Here another stab at the int64 use case. let int64 = (...args) = Object.freeze(new Builtins.Int64(...args)); // int64 is a non-constructable function. It is the normal way of creating Int64 instances // Builtins.Int64 is (at least conceptually) a normal constructor that uses 'new' to create instances but would seldom be directly used in that manner // For Int64 the Object.freeze may actually be redundant but wouldn't necessarily be so if the pattern was extended to structured data. I think this goes in the wrong direction. 'new' implies heap allocation and reference-type semantics. Value objects do not have either. /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 22, 2013, at 6:30 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: ... I agree that int64(x) is nice for int64 (although I would expect such scalar values to me immutable regardless of how you create them). The intuition (supported by other languages) is that 'new' heap-allocates something mutable by default. Stack allocation and (implicit or not) coercion does not. C++ is not far from the mark here, but IIRC C# is similar. pretty much agree, except for the mutable part. There is no reason that a heap allocated entity can't be immutable, by default if it is appropriate for the abstraction. Similar,it is certainly possible to design a language with stack allocated mutable structs. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen Wirfs-Brock wrote: On Jul 22, 2013, at 6:30 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: ... I agree that int64(x) is nice for int64 (although I would expect such scalar values to me immutable regardless of how you create them). The intuition (supported by other languages) is that 'new' heap-allocates something mutable by default. Stack allocation and (implicit or not) coercion does not. C++ is not far from the mark here, but IIRC C# is similar. pretty much agree, except for the mutable part. There is no reason that a heap allocated entity can't be immutable, by default if it is appropriate for the abstraction. Ok, but you are picking a nit. Similar,it is certainly possible to design a language with stack allocated mutable structs. Let's not. On the heap-allocated immutable bit, you'd need to say something extra to opt in. That's JS! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
