Re: Existential operator (was: ||= is much needed?)
So do you have to do it by treating the ?. operator as a standalone? Instead, could you do the indefinte soak part during parsing, treating the rest of the expression differently after having seen a ?. operator? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
On Thu, Jun 21, 2012 at 11:23 AM, Brendan Eich bren...@mozilla.org wrote: John Tamplin wrote: So do you have to do it by treating the ?. operator as a standalone? Not sure what you mean here -- standalone ? (with an English-langauge ? implied after in your sentence? ;-)? Or something else that amounts to a concealed Reference or Nil-value-proxy expression? Just talking spec here: as Allen mentioned, ECMA-262 specifies semantics by evaluating productions in a mostly-LR(1) grammar, so member and call expressions (left-associative) have to result in some kind of (spec-internal or language-external) value. Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux). Yes, and I am suggesting during parsing it gets treated as: (((foo?.bar)?.baz)?.quux) because we saw a ?. operator earlier in the expression. That way you don't have to get the Coffeescript behavior by introducing some fake object or a MaybeReference, and you just implement the ?. operator as always returning the LHS if it is null/undef. Indeed one can translate when parsing. CoffeeScript does this, with some separate passes for its other purposes (implicitly declared variables, indentation-based block structure, etc.). The ES specs can't do this, though, not without a total rewrite. I realize it would be changes, but then so would adding a MaybeReference. Just thought I would bring it up. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
On Wed, Jun 20, 2012 at 12:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: yes, but in a static Java-like language such as for you example above, the existence of person implies the existence of the getName method. The JS equivalent would likely be something like: Is it really rare to write JS code that assumes objects passed to it have an expected structure? Obviously, you don't have to, but when I have seen object-oriented code written in JS it tends to make such assumptions. If I write something that takes either null or a person object, I assume if it isn't null it really is a person object and I don't write checks to verify it. If someone passes something that doesn't have getName on it to my method, I am perfectly fine with it blowing up. When I expect that it might be null/undefined, then I have to write a bunch of boilerplate to deal with that, and ?. allows removing that boilerplate. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Fri, Jun 15, 2012 at 6:00 PM, Brendan Eich bren...@mozilla.com wrote: Can you give a real-world example where null rather than undefined is soaked up? I'm guessing DOM but guessing is bad (cf. Sherlock Holmes). Wouldn't any case where you return null to mean explicitly no object be such a case? Ie: var bar = lookupFoo(key)?.bar(); -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 4:04 PM, Rick Waldron waldron.r...@gmail.comwrote: I realize that the strawman currently spells it ?:, consider this message an opposition to that. This has been an extension to C for quite some time, and it means specifically to use the condition value if it is truthy (and is itself derived from the behavior of a ? a : b). I think it would be a mistake to change that behavior from what is expected. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Thu, Jun 14, 2012 at 5:32 PM, T.J. Crowder t...@crowdersoftware.comwrote: Is ||= really worth it? It would not assign if the left side is truthy, but perhaps no one will mind. Nice-to-have. The fact it doesn't assign if the left side is truthy is the only reason for having it, surely? Plus not even evaluating the RHS if the LHS is truthy -- useful if the default is an expensive calculation. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich bren...@mozilla.org wrote: And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. Wouldn't you want B to be evaluated only if A is undefined? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Sun, Jun 10, 2012 at 5:31 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon gsned...@opera.com wrote: As such, I'm somewhat dubious as to whether we can actually change the format that much without breaking sites. For reference, we support Error.stack (supposedly identical to SpiderMonkey in format, though obviously not) and Error.stacktrace (which is meant to actually be human readable). Originally, we had Error.stacktrace as Error.stack, but it just broke too much (we spoof UA on some Google sites by default, and have to choose whether to go down IE/Fx/WK code-path, and often all three rely upon non-standard behaviour). [1]: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java This looks pretty broken to me as is. It does not seem to work correct for the V8 style formatting that is used by Chrome and IE. Note that GWT uses deferred binding to substitute browser-specific implementations for the version being compiled -- see http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/CoreWithUserAgent.gwt.xml where the mappings are defined. So, for Chrome, CollectorChrome is used instead of Collector. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Sun, Jun 10, 2012 at 9:56 AM, Geoffrey Sneddon gsned...@opera.comwrote: It's not just Firefox addons that will break: GWT's output relies upon the exact format of Error.stack[1]. I know Google Wave depended upon this, and I believe other Google applications do too. Note that GWT can supply different deferred-bound implementations for different browsers, though generally we do runtime detection rather than compile time if there are few differences between versions. Of course, that would only affect deployed apps if they recompiled, but I wouldn't expect that would be much of a problem for any currently maintained apps. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Mon, Jun 4, 2012 at 12:54 PM, Brendan Eich bren...@mozilla.com wrote:
Angus Croll wrote:
I actually agree. I included non-this methods only because reading
through this thread I got a feeling that there was some consensus that
they be treated differently. More than happy to not do that.
You mean you still propose that (= 42).call({}) should throw, but
(function () { return 42; }).call({}) should not?
Sorry, this isn't a principled response. There should be no difference in
result between those two cases.
And the other cases where this is bound should be treated identically:
var self = this;
return function () { self; }
return function () { this...; }.bind(this);
return = this...;
Aside from the last, these cases already are options that could be passed
to an API that expects to use this as a hidden parameter. Why should the
last be treated differently than the other two?
I don't object to having a non-bound arrow, but aside from jQuery's (IMHO)
misuse of this, the bound-this case seems to be the most prevalent and the
least likely to confuse people.
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Tue, Jun 5, 2012 at 12:56 PM, Russell Leggett russell.legg...@gmail.comwrote: I think that the dynamic |this| behavior of jQuery is not something that should be encouraged. I understand it is probably mostly that way because of the dom event api, but that doesn't change the fact that it really has a bad smell to it. +1 -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
If you are using call anyway and passing the array as thisObj there, why do you need to do the bind at all? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 meeting Wed 5/23/2012
On Tue, May 29, 2012 at 1:15 PM, John J Barton johnjbar...@johnjbarton.comwrote: 1) The advertised advantages of use strict (https://developer.mozilla.org/en/JavaScript/Strict_mode) seem very minor to me. I've never had any of the problems it solves and -- until recently -- I've never encountered freeze in real code. If silent failures on writing to a frozen object are as much a concern to you as you suggest, then that sounds like reason enough. If they aren't that much of a problem, then why do you care about the issue enough to break backwards compatibility for those that do care? 2) I had legacy code using with. You probably want to rewrite such code even if you aren't using SES -- check out the performance implications. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote: I'm not sure if this makes sense, but something about breaking `call` and `apply` doesn't sit right with me. Why should an arrow function be treated any differently than an explicitly bound function (ie, via bind)? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 meeting Wed 5/23/2012
On Tue, May 29, 2012 at 12:07 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
function app() {
var r = makeExample();
r.discover = function() {
console.log(I want to call this function);
return 1;
};
r.discover();
}
The result is an error message at the
Uncaught TypeError: Object #Object has no method 'discover'.
Isn't this code broken in either case? The only question is whether you
get an exception when you create discover() or when you call it. Your code
can choose or not to treat adding properties to frozen objects as a fatal
error or not, but the code is going to fail if r is frozen no matter what.
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 meeting Wed 5/23/2012
On Tue, May 29, 2012 at 12:45 AM, John J Barton johnjbar...@johnjbarton.com wrote: The only question is whether you get an exception when you create discover() or when you call it. Your code can choose or not to treat adding properties to frozen objects as a fatal error or not, but the code is going to fail if r is frozen no matter what. This is not correct. (Well to be sure, I am assuming that you meant to write: You can choose... because, of course, 'code' cannot choose.) I do not have this choice. I wrote the code and I got the error. You have the choice of using strict mode in your code, and getting the error when you try and create discover(). Note that the decision embodied in your code is independent of the decision made by the library writer, as the same would apply if the library were written in non-strict mode. Regarding the original decision to have silent failures on modifying a frozen object, that is just one of many quirks you just have to know if you are going to write JS. Just like putting a line break after a return keyword, you only have to do it once and you will remember not to do it again. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: bind operator (was: arrow function syntax simplified)
On Wed, Mar 28, 2012 at 2:02 PM, Russell Leggett
russell.legg...@gmail.comwrote:
Ah, there you go. I figured I wasn't the first to think of it. I think it
might be worth talking about this in relation to the shorthand function
syntax, because it could pull the lexical this issue out of that debate.
Then we could reduce the arrows to something simpler: - for blocks, = for
expressions with implicit return. It would also solve the related issue of
this binding when passing methods as callbacks, which is also a major issue
in a lot of apis, requiring extra parameters for the this.
To me, the biggest problem when you need bound this is that you have to
keep around the bound version so you can remove it. For example:
elem.addEventListener('click', onClick.bind(this));
...
elem.removeEventListener(type, ???);
I can't remove the bound listener unless I saved a reference to it, since
another bind with the same callback and object reference gets a new bound
function. This adds a lot of extra work, and makes it easy to leak memory.
If the function already had a bound this by the way it was defined, I don't
need to keep an extra reference around (this assumes some class syntax that
allows the same function shorthands:
class Foo {
register(elem) {
elem.addEventListener('click', onClick);
}
unregister(elem) {
elem.removeEventListener('click', onClick);
}
onClick(e) = do {
...
}
}
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExps in array functions
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if it doesn't? It does, if you bind it to the regex first. Ie: var re = /foo/i; var filtered = array.filter(re.test.bind(re)); So that doesn't look better than just passing an anonymous function wrapper (though you probably want to build the regex once). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional function keyword
On Wed, Mar 7, 2012 at 8:31 PM, Kevin Smith khs4...@gmail.com wrote: // Or () = expr You don't need TCP here, since there is no return. Bound this would be nice, since it is a new form that can't break existing code. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional function keyword
On Thu, Mar 8, 2012 at 1:08 PM, Brendan Eich bren...@mozilla.org wrote:
Another which I cited just a few messages back: parsing ( params ) as (
expr ), as any top down parser must until it gets to an arrow or other
distinguishing token ({ on same line as ), e.g.), can be considered
future-hostile. params should be declarative, but expr must now cover all
future declarative syntax, including optional guards.
For this particular problem, the Dart parser looks ahead to see if it could
be a function declaration. If so, it parses it that way, otherwise it
parses as a parenthesized expression. I don't know if this sort of
approach would be considered acceptable here or not (it does impose some
restrictions on the scanner for n-token lookahead).
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
On Wed, Feb 15, 2012 at 4:55 AM, Andreas Rossberg rossb...@google.comwrote: On 15 February 2012 07:47, Mark S. Miller erig...@google.com wrote: clear() is ok. Also, java.util.Map and java.util.Set use clear() so it would also be familiar to many people. Perhaps deleteAll() would be more mnemonic, as its relationship with delete() would be obvious? +1 for deleteAll. Give related names to related operations. deleteAll would seem better reserved for deleteAll(Collection), which would remove every element present in the collection. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Tue, Feb 14, 2012 at 10:13 PM, Brendan Eich bren...@mozilla.org wrote: Is this comparable with JS? Interop on the web is a harsh mistress. The C-Python vs. IronPython vs. PyPy vs. etc. situation is more of a porting model with one-way forks. Java seems comparable, in that compiled code is expected to run on different JVMs. I'm not aware of any Java code that relies on a particular iteration order where it is unspecified in the API. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Nested Quasis
I think this could take the same approach as Dart in dealing with embedded expressions - http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/compiler/java/com/google/dart/compiler/parser/DartScanner.java?r=1805#898 Basically, the scanner returns token sequences like: foo = STRING(foo) foo $bar baz = STRING_SEGMENT(foo ) STRING_EMBED_EXPR_START IDENTIFIER(bar) STRING_EMBED_EXPR_END which the parser then handles normally, with rules like: string-expression : STRING | string-interpolation ; string-interpolation : ( STRING_SEGMENT? embedded-exp? )* STRING_LAST_SEGMENT ; // a simplification embedded-exp : STRING_EMBED_EXP_START expression STRING_EMBED_EXP_END ; I don't know if this would cause ambiguities in the JS grammar, or if it would have other issues applying it to quasis in JS, but it keeps a clean separation between the scanner and parser (it does require some additional state in the scanner, since these can be nested). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about the “full Unicode in strings” strawman
On Wed, Jan 25, 2012 at 12:46 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: Arbitrary 16-bit values can be placed in a String using either String.fromCharCode (15.5.3.2) or the \u notation in string literals. Neither of these enforce a requirement that individual String elements are valid Unicode code units. You can't really store arbitrary 16-bit values in strings, as they will get corrupted in some browsers. Specifically combining marks and unpaired surrogates are problematic, and some invalid code points get replaced with another character. Even if it is only text, you can't rely on the strings not being mangled -- GWT RPC quotes different ranges of characters on different browsers. http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamWriter.java?spec=svn10146r=10146#86 (the Android bug mentioned has been fixed long ago, but I haven't gone through any kind of research to see how many of the broken browsers are still in use to see if it is safe to remove). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about the “full Unicode in strings” strawman
On Wed, Jan 25, 2012 at 2:33 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: It isn't clear from your source code what encoding issues you have actually identified. I suspect that you are talking about what happens when an external resource (a application/javascript file) which may be in various UTF encodings is normalized and passed to the JavaScript parser. If so, that isn't what we are talking about here. We are talking about what values can exist at runtime as the individual elements of a string value. No, I am talking about storing values directly in a string in JS, sending them to a server via XHR, and have them arrive there the same as they existed in JS. There are tests in GWT that verify that, and without replacing certain values with escape sequences (which get reversed on the server), they do not make it unmangled to the server (and inspecting the packets on the wire shows the mangling happens in the browser not the server). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about the “full Unicode in strings” strawman
On Wed, Jan 25, 2012 at 2:55 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
The primary intent of the proposal was to extend ES Strings to support a
uniform represent of all Unicode characters, including non-BMP. That means
that any Unicode character should occupy exactly one element position
within a String value. Interpreting \u{10} as an UTF-16 encoding does
not satisfy that objective. In particular, under that approach
\{10}.length would be 2 while a uniform character representation
should yield a length of 1.
When this proposal was originally floated, the much of debated seemed to
be about whether such a uniform character representation was desirable or
even useful. See the thread starting at
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014252.html also
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014316.html and
That seems highly likely to break existing code that assumes UTF16
representation of JS strings.
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
On Wed, Dec 28, 2011 at 11:39 AM, John-David Dalton john.david.dal...@gmail.com wrote: As for the issue of using objects as dictionaries you can simply prefix keys with some unique value, `var uid = 'uid' + (+new Date);`, and then access entries like `dict[uid + key]`. This will allow value lookups to work correctly cross-browser regardless of ES5+ or __proto__ support. At the expense of creating lots of garbage and slowing things down. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
On Wed, Dec 28, 2011 at 12:43 PM, John-David Dalton john.david.dal...@gmail.com wrote: At the expense of creating lots of garbage and slowing things down. A prefix is hardly `lots of garbage` and the perf hit is not a real concern (millions of ops/sec vs higher millions of ops/sec). In GWT, we did exactly this prefix operation, and we found GC became a problem on IE because of it, as each lookup or store in the map creates a new garbage string. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String concatenation
On Wed, Oct 5, 2011 at 12:10 PM, Axel Rauschmayer a...@rauschma.de wrote: The two concatenation approaches I know of are: 1. via += 2. push() into an array, join() it after the last push() (1) can’t possibly be efficient, Huh? Engines have optimized the hell out of 1 by essentially doing 2 under the hood. Even rhino's about a land a patch to do just that. but if (2) is OK on all(!) platforms, then a library would be OK. However, given how frequently this is used, I would like this to become part of the standard library. What exactly do you want supported? Something like Java’s StringBuilder. If, however, (2) collects the concatenated substrings and only joins them on demand in current engines, then there is indeed no need for such a thing. GWT's implementation of StringBuilder actually uses both methods #1 and #2 under the hood, because each is faster on different browsers (due to deferred binding, you only get the implementation for the browser you are using and parts of it can be inlined at call sites so you don't pay the penalty for multiple implementations). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for NumberFormat and DateTimeFormat constructors
On Tue, Aug 16, 2011 at 7:57 PM, Norbert Lindenberg ecmascr...@norbertlindenberg.com wrote: The current specs for the NumberFormat and DateTimeFormat constructors in the ECMAScript internationalization API provide for 3 (NumberFormat) or 2 (DateTimeFormat) different ways to specify the desired formats: using style properties, using skeleton properties, and (for NumberFormat) using patterns. Skeletons for NumberFormat are awaiting clarification, and Eric (Microsoft) has proposed an alternative for DateTimeFormat skeletons. I've been thinking about how this can be streamlined, and would like to propose: 1) Remove patterns from NumberFormat. I can imagine a few clients for which patterns would be useful, such as spreadsheet-type applications or value-added internationalization libraries. However, they require clients to provide localized patterns, and the number of applications for which this is both necessary and reasonable is fairly small. Most applications are better off using styles or skeletons, which let the implementation of the internationalization API fully take care of localization. (Patterns would actually be more useful for DateTimeFormat, where the limited number of supported skeletons will force more clients to roll their own, but there we don't offer them.) Maybe we are calling different things patterns, but if I pass in #,###.00 as the pattern to ICU4J's DecimalFormat, then that will get localized to the proper grouping separator, number of grouping digits, and decimal separator -- the caller doesn't have to localize it at all. I think more applications than you think will want some control over the format pattern -- for example, if I am showing a table of currencies, I probably don't want to include the currency symbol in every cell in the table, but I still want them formatted appropriately for the currency (right number of decimal positions, round to multiple of .05 for CHF, etc). I would argue that patterns are actually less useful in DateTimeFormat, as it encourages developers to do the wrong thing. Ie, if I use MM/dd/ as the pattern for DateTimeFormat, then the result will be misleading in locales where such a date would be formatted as dd/MM/. I think it would be better to support skeleton patterns instead, where the app asks for a pattern containing numeric days, months and a 4-digit year, and then it gets the proper localized pattern that matches that. The one case where specifying patterns explicitly is useful is compliance with specs - for example, RFC2822 or ISO8601 dates (which also need to force English names in the cae of RFC2822). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote: This may of been thrown though the ringer already but I thought I'd ask. http://blog.stevenlevithan.com/archives/date-time-format This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular. See http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api Note that it is rarely useful to format with a fixed pattern, because different locales have different norms for ordering of the fields, separators, etc. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 12:21 PM, Marc Harter wav...@gmail.com wrote:
Note that it is rarely useful to format with a fixed pattern, because
different locales have different norms for ordering of the fields,
separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so,
doesn't that allow for more expressive power?
To illustrate the problem, consider formatting a date next week with
M/d/y, giving 6/1/2011. US readers will understand that readily.
However, if a European user sees that, they will interpret it as if it were
d/M/y, and they will think it is in January. Also, many locales have
different separators for the portions of the date, or insert additional
words in the longer formats, which won't be present if you just used a fixed
format pattern.
Instead, you should use a skeleton pattern of Mdy saying that you want a
format with numeric values for month day and year. Then, you get the proper
format for the locale your user is running your app in. Even better, though
more restrictive, is to use a predefined format where experts in each locale
have said this is a good short date format for that locale, since there
are different conventions.
For examples from CLDR, see:
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1259
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en_GB.xml#L57
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1166
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1217
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1123
Certainly, there are cases where you do want a fixed format (and in fact you
don't want localized names, but rather the English month/day names), such as
when formatting an RFC2822 date, and in those cases you do want to be able
to use a fixed format string.
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 4:59 PM, Adam Shannon a...@ashannon.us wrote: I like the idea of putting .format() on the Date; it would allow for quick and easy access to a handy formatter. However, would it make more sense to use the set that php uses to format dates?[0] I would assume that developers would be more familiar with that. [0]: http://us3.php.net/manual/en/function.date.php Since that isn't the format used in CLDR, you would have to translate the localized formats to that. Also, you can't properly localize date formats for all the locales given that, since for example it doesn't support the concept of standalone vs non-standalone month names. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 4:43 PM, Peter Michaux petermich...@gmail.comwrote: Yes but I was thinking of the use of guards as a debugging/development tool. During development you can verify that foo is never called with bad values. Then during production, those checks do not need to be performed. By removing the debugging checks for production, this would save wire and execution time. Sure, until a user typed in a value you never tried during development. You can either rely on these for validating arguments, in which case they have to stay, or you can't, in which case you can treat them like asserts. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n NumberFormat and skeleton (in addition to pattern parameter)
On Mon, May 23, 2011 at 2:50 PM, Nebojša Ćirić c...@google.com wrote: I should have used ¤ (\u00A4) instead of $. So ¤ gets replaced with proper currency symbol/code. Actually, I assume it just marks the format as a currency format, and the currency symbol gets positioned according to the locale/currency rules, right? As Mike mentioned, there definitely needs to be a way to pass the currency code of the number being formatted into the formatter. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
On Wed, May 18, 2011 at 6:35 PM, Nebojša Ćirić c...@google.com wrote: 4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/* dateTimeFormat*() into LocaleInfo.*createCollator*()...? It makes it clear we are creating new object. The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods. In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor? They are prototypes: LocaleInfo.prototype.collator() I propose LocaleInfo.prototype.createCollator() since they actually create a new LocaleInfo.Collator (or DateTimeFormat or NumberFormat) objects based on that locale info. Are they required to create new instance, or can they return a cached object that uses the same parameters? If the latter, then I would suggest either foo() or getFoo() rather than createFoo(). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UTF-16 vs UTF-32
On Mon, May 16, 2011 at 8:42 PM, Shawn Steele shawn.ste...@microsoft.comwrote: It's clear why we want to support the full Unicode range, but it's less clear to me why UTF-32 would be desirable internally. (Sure, it'd be nice for conversion types). What UTF-32 has that UTF-16 doesn't is the ability to walk a string without accidentally chopping up a surrogate pair. However, in practice, stepping over surrogates is pretty much the least of the problems with walking a string. Combining characters and the like cause numerous typographical shapes/glyphs to be represented by more than one Unicode codepoint, even in UTF-32. We don't see that in Latin so much, especially in NFC, but in some scripts most characters require multiple code points. In other words, if I'm trying to find safe places to break a string, append text, or many other operations, then UTF-16 is no more complicated than UTF-32, even when considering surrogates. UTF-32 would cause a huge amount of ambiguity though about what happens to all of those UTF-16 sequences that currently sort-of work even though they shouldn't really because ES is nominally UCS-2. Personally, I think UTF16 is more prone to error than either UTF8 or UTF32 -- in UTF32 there is a one-to-one correspondence, while in UTF8 it is obvious you have to deal with multi-byte encodings. With UTF16, most developers only run into BMP characters and just assume that there is a one-to-one correspondence between chars and characters. Then, when their code runs into non-BMP characters they run into problems like restricting the size of a field to a number of chars and it is no longer long enough, etc. The problems arise infrequently, which means many developers assume the problem doesn't exist. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictabilityandcontrol; alternatives
On Tue, Apr 19, 2011 at 11:52 AM, Brendan Eich bren...@mozilla.com wrote: So ASI does *not* change program behavior from non-error behavior A to non-error behavior B. It instead suppresses early SyntaxError with successful evaluation, in a deterministic way. Is that true even in the return \n expression case? It certainly seems to be not an error before or after ASI, yet the result is quite different. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On Tue, Apr 19, 2011 at 2:53 PM, Bob Nystrom rnyst...@google.com wrote: I think there are a large number of programmers who, because of those java style guidelines and the way ASI works, write javascript breaking before operators except for comma operators. http://www.google.com/codesearch?q=%5Cx20%5Cx20%5Cx20%5B%2B-%5D%5B ^%2B-%5D+lang%3Ajavascript shows numerous examples. If true, this is not just a matter of code backwards compatibility, but of porting programmers. That's unfortunate. There's another option: Python-style. In Python, I believe newlines are ignored within a parenthesized expression. In JS, that would mean: var a = 1 + 2 // a = 1 var a = (1 + 2) // a = 3 Ok, so you are advocating that adding extra parens is less typing and less prone to error than adding semicolons? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictabilityandcontrol; alternatives
On Tue, Apr 19, 2011 at 6:22 PM, Brendan Eich bren...@mozilla.com wrote: Yes. We've discussed this. It's not a change in semantics due to the error-correction aspect of ASI. There is no ASI on this concatenated input! Yes, but given that ASI encourages developers to omit semicolons except when absolutely required, it is nevertheless a consequence of ASI. If ASI did not exist, the would be no missing semicolons. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote: Web developers find and exploit many de-facto standards. Enumeration order being insertion order for non-arrays at least, if not for all objects (arrays tend to be populated in index order), is old as the hills and web content depends on it, as far as I can tell. I'll do some experiments to try to get data on this. Aside from the JSON example of populating a dropdown list given (which I will agree is a real if contrived use case), there has been a lot of talk of thousands of web developers depending on preserving insertion order, but not one concrete example -- do you have one? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Sun, Mar 13, 2011 at 5:57 AM, Claus Reinke claus.rei...@talk21.comwrote: Please note that this use case highlights the highjacking of numeric Strings as indices, not the lack of overall property addition order including indices. A spec workaround would be to stop converting numeric keys to Strings, ie, 1 and '1' would be different keys. Then number keys could behave as Array indices, while String keys would behave as other properties. This would avoid the gaps in the String keys highlighted by your use case, but you would still not get a full record of insertion order. Doing that might make insertion ordering slightly more palatable, though. Btw, if you really need to organize your music now, and don't feel like using a proper LinkedHashMap, you could prefix all your keys with ':' or something similarly non-numeric;-) That would avoid the auto-conversion/index ordering, at the price of messing up your access code. If you are trying to use an object to store arbitrary values as a hash map, you already have to do something like this -- otherwise you run into problems with trying to store various values like prototype, __proto__, watch, etc. (and the list of dangerous values varies by browser). If you know your data can't conflict, then of course you can use it directly, but then you are likely to have subtle bugs when your assumption turns out to be wrong. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Fri, Mar 11, 2011 at 11:31 AM, Charles Kendrick char...@isomorphic.comwrote: However as far as the default strategy, the highest value thing to do seems to me to impose the de-facto standard of 15 years - insertion order - which is a very useful behavior and will avoid thousands of websites having to compensate for a change in de-facto standard behavior. So I suppose you think C should have kept int at 16 bits since there was lots of Win16 code that assumed sizeof(int)==2 because it happened to work on their platform, or likewise sizeof(int)==sizeof(char*)? Things unspecified in the spec mean unspecified -- it doesn't mean rely on whatever behavior the implementation you use exhibits and expect it to be portable. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Fri, Mar 11, 2011 at 2:49 PM, Charles Kendrick char...@isomorphic.comwrote: Hello John, I'll assume you meant this as humor since the analogy has such obvious flaws. Having a default strategy on Object of maintaining order obviously does not preclude other strategies, nor does it damage the JavaScript language itself, as locking int to 16 bits would obviously have damaged C by requiring various new types. There is a non-zero cost of maintaining insertion order, and doing so introduces many edge cases that have been discussed. The most obvious implementation of object properties is a hash map, which does not support what you want. Aside from the technical issues, the point remains that if you write code that depends on unspecified implementation details, you should not expect that code to be portable. I think analogy with C is appropriate -- the sizes and implementation details of basic types were left unspecified, largely because specifying a particular size or representation would have made it inefficient to implement on some platforms. Sure, that meant that people had to define their own int16/int32/etc types where they cared and certainly some people wrote code assuming twos-complement or int/pointer equivalence and were surprised when the code didn't run on some other platform, but it also allowed the language to be efficiently implemented on lots of different platforms and to grow to platforms never imagined when it was first designed. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Thu, Mar 10, 2011 at 9:00 PM, Charles Kendrick char...@isomorphic.comwrote: People use Objects as classes, instances, associative arrays / Maps, etc. Numeric keys are a tiny minority and there would be no measurable performance gains for special treatment of such keys *on Object*. An associative array is typically a hash map or perhaps a tree map. A typical implementation will either iterate through such values in either an undetermined order or in order by the keys -- preserving the insertion order would be more expensive and preclude most options for implementation. If you care about order, you don't use a hash map, and a JS object literal seems more closely related to a hash map than anything else. An alternative you didn't consider in your original post is using a single array, which is guaranteed to not change the order and never pick up additional properties: selectControl.setOptions([ storedValue1, displayValue1, storedValue2, displayValue2, storedValue3, displayValue3 ]) -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
