Globalization: DateTimeFormat patterns and styles

This message includes strawman proposals for (a) a simplified pattern syntax and (b) simple style specifiers for DateTimeFormat objects, which can replace the current format specification through nine separate properties for the components of formatted date and time. Several people have recently

Re: ES6 “modes” and user-friendliness

On Jan 16, 2012, at 10:30 PM, Axel Rauschmayer wrote: > Lastly, there is one aspect of automatic language version detection that I > still don’t understand: With David Herman’s solution, I’d expect browsers to > first scan all of the code and then determine what semantics to use (at least > con

ES6 “modes” and user-friendliness

| OB | NB | +++ OC ||| +++ NC ||| +++ (OC = Old Code, NC = New Code, OB = Old Browser, NB = New Browser) If we are talking about keeping JavaScript user-friendly, we have actually only tackled the second column: How new browsers handle ol

RE: Globalization API holiday summary

According to the current API on http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders along with an assumption (not yet decided) that the system loader would be at Object.system, you would want this for the example shown below: var intl = Object.system.loaded['@globalization'] intl.

Re: Harmony modules feedback

On Mon, Jan 16, 2012 at 9:44 PM, John J Barton wrote: > Doesn't "Script-loader" make about as much sense as literal "XML HTTP > Request"? Imagine how impoverished our Web App world would be if it had > turned out that Ajax only supported valid XML. > > Shouldn't the API > in http://wiki.ecmascript

Re: Harmony modules feedback

On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak wrote: > The point is that there are two ways of thinking of modules, first is fine > grained, when you care about DRY then your modules are rather small, it > means that with AMD you would need to load hundreds of such modules > asynchronously it wo

Re: Harmony modules feedback

On Mon, Jan 16, 2012 at 9:07 PM, James Burke wrote: > > I believe loader plugins are much more valuable to the end developer > than the possible advantages under the covers to compile time wiring. > (I hope this is related; if not, just erase this line and the two quoted above). Doesn't "Script

Re: Harmony modules feedback

Again, I sent only to Axel, but meant for the list, resending... On Thu, Jan 12, 2012 at 1:57 AM, Axel Rauschmayer wrote: > I think introducing new language constructs for modules is good, because > they are so fundamental. For incrementally migrating old code bases, it > would make a lot of sens

Re: Harmony modules feedback

Apologies to Sam, I sent this feedback to just him earlier, but meant it also for the list, so resending: On Thu, Jan 12, 2012 at 5:16 AM, Sam Tobin-Hochstadt wrote: > As to your current post, I think the fundamental disagreement is all > encapsulated here: >  "ES harmony may be able to do someth

Re: Globalization API holiday summary

I can't find a specification for Object.system.load - does it return a reference to a single globally shared object representing the module, or does it return a new object that contains the exported functions/items of the module? In the first case, I'd assume the object returned is immutable for

Re: Globalization API holiday summary

A few comments below. Norbert On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote: > There are couple of threads going on and I wanted to wrap up current state > before the holidays... > > API: > 1. Use built in toLocaleString family of methods in simple, functional case* > 2. Use Globalization

Re: Globalization API - Sample Use Cases

I don't think a standalone pattern string is sufficient - the pattern doesn't encode all information that the DateTimeFormat needs. In this version of the API, we need at least the timeZone option, in a later version probably also a calendar option. Norbert On Dec 6, 2011, at 11:42 , Nicholas

Re: String.prototype.[de]normalize and .isCharXxx are needed

Nothing planned at this point. Unicode normalization would be a natural candidate for the Globalization API, but it's not in scope for version 1. Support for Unicode character properties probably should be part of regular expressions, as it is in Perl, PHP, Java, and other platforms; there was a

Re: ES6 opt-in, reloaded

On Jan 16, 2012, at 6:00 PM, Allen Wirfs-Brock wrote: > On Jan 16, 2012, at 5:49 PM, David Herman wrote: > >> On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote: >> >>> One of the thing that an "ES6" (or "extended code" as it is currently known >>> in the ES6 draft) mode that is distinct fro

Re: ES6 opt-in, reloaded

On Jan 16, 2012, at 5:49 PM, David Herman wrote: > On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote: > >> One of the thing that an "ES6" (or "extended code" as it is currently known >> in the ES6 draft) mode that is distinct from "strict mode" does is allow us >> do add additional Early E

Re: ES6 opt-in, reloaded

On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote: > One of the thing that an "ES6" (or "extended code" as it is currently known > in the ES6 draft) mode that is distinct from "strict mode" does is allow us > do add additional Early Errors that aren't in ES5 for various existing > construct

Re: ES6 opt-in, reloaded

One of the thing that an "ES6" (or "extended code" as it is currently known in the ES6 draft) mode that is distinct from "strict mode" does is allow us do add additional Early Errors that aren't in ES5 for various existing constructs. It isn't clear that we could continue to have add these err

Re: Block Lambdas: break and continue

Brendan Eich wrote: > 2. Variation on empty label: support "do" as a reserved-identifier label > >   do: arr.forEach {|o| >     if (...) break; >     ... >   } This seems like a sound way of doing it, indeed (I omitted your first one because I prefer this one). It avoids the more egregious syntax

Re: A different semantics for WeakMap#get default value

For what it’s worth, Python dictionaries have .get(key, default) and .setdefault(key, default). The former is non-mutating. Its behavior is also different depending on arguments length. If the default is not passed, it will throw an exception. If a default is passed, even if that default is Non

Re: A different semantics for WeakMap#get default value

it's OK, 'cause is not called get ;-) On Tue, Jan 17, 2012 at 1:46 AM, Kris Kowal wrote: > On Mon, Jan 16, 2012 at 4:39 PM, Andrea Giammarchi > wrote: > > then the method should be called "getOrSetIfNotThere(obj, def)" 'cause > get() > > would mislead too much > > I’ve been calling this method

Re: A different semantics for WeakMap#get default value

On Mon, Jan 16, 2012 at 4:39 PM, Andrea Giammarchi wrote: > then the method should be called "getOrSetIfNotThere(obj, def)" 'cause get() > would mislead too much I’ve been calling this method "getset" for about three years, hoping it would catch on :P https://github.com/kriskowal/narwhal-lib/blo

Re: A different semantics for WeakMap#get default value

On Tue, Jan 17, 2012 at 1:39 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > the second one *def* will be returned if obj was in the WeakMap > sorry for the typo, I meant if obj was *not* in the WeakMap ... pretty sure you got it br ___

Re: A different semantics for WeakMap#get default value

then the method should be called "*getOrSetIfNotThere(obj, def)*" 'cause get() would mislead too much looks to me we are also confusing falsy with undefined ... undefined is undefined and there's no reason to use a WeakMap to set undefined since I would expect the WeakMap itself to completely igno

Re: It's been a long time coming...

This is really exciting - I can't wait to dig in here. To everyone involved: Great work! On Mon, Jan 16, 2012 at 5:29 PM, Dave Fugate wrote: > …but test262 finally > standsat > zero (known) inv

Re: ES6 opt-in, reloaded

On Jan 16, 2012, at 2:47 PM, Brendan Eich wrote: > If we have already gone too far in terms of runtime "five fingers of fate" > changes with completion reform, we can pare back. But I'd like to give c.r. a > chance -- it may be non-breaking. Yes, absolutely. I believe it's got non-breaking pote

Re: ES6 opt-in, reloaded

David Herman January 16, 2012 2:18 PM The goal that is missing, and what I believe is the single most important part of my New Year's email, is:9. Allow programmers to continue thinking of JS as a single cohesive language. Thanks, this is the transcendant usabilit

Re: Block Lambdas: break and continue

On Jan 16, 2012, at 11:32 AM, Allen Wirfs-Brock wrote: >> I have some angst about loss of a hunk of code running "break L" up against >> " with (E)\nS" where E is an expression and S is a statement and the two >> came from a bone-fide with statement later in the unmangled source. > > that's why

Re: Harmony modules feedback

On Jan 16, 2012, at 1:02 PM, Axel Rauschmayer > > From where I’m standing, AMD is already a standard in browser space. By definition, AMD not a "standard" in the browser space. I challenge anyone to cite more then 5 high traffic sites that actually use AMD. Don't get me wrong, I'm not oppose

Re: Block Lambdas: break and continue

On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote: > With completion values as In ES1-5, not even depending on > http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be > enough to say: > > >foo {|| >exit: { > ... > if (...) { >

Re: Block Lambdas: break and continue

On Jan 15, 2012, at 11:32 PM, Axel Rauschmayer wrote: > Could we call block lambdas just lambdas? The former seems a bit pleonastic. Block lambdas is a proposal that combines block-based syntax with lambda-based semantics. There have been other proposals in the past which provide lambda semanti

Re: A different semantics for WeakMap#get default value

Axel Rauschmayer January 16, 2012 2:33 PM All boolean parameters are anti-patterns? All optional boolean parameters? What’s the alternative? I'm talking about formal parameters here. I thought that boolean parameters where OK when they were labeled in some mann

Re: A different semantics for WeakMap#get default value

> Mark objected to the mutating-option-for-"get" overloading. I've agreed but > wanted to go further here: optional trailing boolean parameters are an > anti-pattern. I'm leaning toward thinking that all boolean option params are > an anti-pattern. All boolean parameters are anti-patterns? All

Re: A different semantics for WeakMap#get default value

I’m not sure how much this is needed for WeakMaps in particular, but when you nest data structures then it’s handy to automatically create an entry if it is missing. I’ve seen collection frameworks where maps have an optional constructor argument: a function that auto-creates an entry if it is

Re: A different semantics for WeakMap#get default value

On Mon, Jan 16, 2012 at 2:11 PM, David Bruant wrote: [...] > > What additional value does this contingent mutation add, regardless of > > how it's packaged? > What additional value adds the default value when something very close > is achieved with "wm.get(o) || defaultValue"? > Do you have use c

Re: ES6 opt-in, reloaded

On Jan 16, 2012, at 8:09 AM, Andreas Rossberg wrote: > 1. Make ES6 opt-in as convenient as possible. > > 2. Avoid reliance on external features like script tags or mime types. > (Not all JS is on web pages anyway!) > > 3. Provide as many incentives for switching to ES6 as possible. > > 4. Minim

Re: Block Lambdas: break and continue

Allen Wirfs-Brock January 15, 2012 2:31 PM We could try for other syntax, but it too would have the body-less problem. Unless we use a new keyword: loop arr.forEach { |o| if (...) break; } Even though these are not necessarily "

Re: A different semantics for WeakMap#get default value

Le 16/01/2012 22:46, Mark S. Miller a écrit : > David and Axel, I don't get it. What's wrong with the get with the > optional default value, as specified by that text and as currently > implemented by FF? This discussion started with me saying that "var v = wm.get(o, someValue);" could be a shortcu

Re: A different semantics for WeakMap#get default value

Le 16/01/2012 21:56, Mark S. Miller a écrit : > I like the idea of the two argument get as proposed by David. (In > fact, I like it so much that I thought I'd already specified it that > way ;).) David, I'm glad to see you got it right in your suggestion at >

Re: A different semantics for WeakMap#get default value

Mark objected to the mutating-option-for-"get" overloading. I've agreed but wanted to go further here: optional trailing boolean parameters are an anti-pattern. I'm leaning toward thinking that all boolean option params are an anti-pattern. /be Axel Rauschmayer January 16

Re: A different semantics for WeakMap#get default value

Clearly(!) a set-if-not-present method should not be misnamed "get". I like the optional sentinel-meaning-not-found for get, and setDefault per Python as Tab pointed out. Agree they should not be merged into one API. Bikeshedding setDefault at leisure (in background in my head ;-). /be __

Re: A different semantics for WeakMap#get default value

I think I agree with current wm.get(o, def) which is indeed the one implemented in Firefox and all other shims I have seen so far ... I don't agree about the third argument to set it automatically if not there: a bit too much for a get semantic, imho On Mon, Jan 16, 2012 at 10:46 PM, Mark S. Mille

Re: A different semantics for WeakMap#get default value

David and Axel, I don't get it. What's wrong with the get with the optional default value, as specified by that text and as currently implemented by FF? What additional value does this contingent mutation add, regardless of how it's packaged? Do you really want "has" to answer true for a key merely

Re: A different semantics for WeakMap#get default value

A separate method such as the previously mentioned setdefault() provided by Python [1] might answer both Mark’s concerns and yours. [1] http://docs.python.org/dev/library/stdtypes.html#mapping-types-dict On Jan 16, 2012, at 22:21 , David Bruant wrote: > [Specifying the Davids] > > Le 16/01/20

Re: A different semantics for WeakMap#get default value

[Specifying the Davids] Le 16/01/2012 21:56, Mark S. Miller a écrit : > I like the idea of the two argument get as proposed by David [BRUANT]. > (In fact, I like it so much that I thought I'd already specified it > that way ;).) David [HERMAN], I'm glad to see you got it right in your > suggestion

Re: A different semantics for WeakMap#get default value

I would also say that if you can carry both the keyObject and its defaultValue with you all the time you may not need at all to store it as weak map ... looks to me you are missing the point where the relation should be created, using the get() as generic action/entry point to do that. I believe r

Re: A different semantics for WeakMap#get default value

On Mon, Jan 16, 2012 at 12:56 PM, Mark S. Miller wrote: > I like the idea of the two argument get as proposed by David. (In fact, I > like it so much that I thought I'd already specified it that way ;).) > David, I'm glad to see you got it right in your suggestion at < > http://wiki.ecmascript.or

Re: A different semantics for WeakMap#get default value

I like the idea of the two argument get as proposed by David. (In fact, I like it so much that I thought I'd already specified it that way ;).) David, I'm glad to see you got it right in your suggestion at < http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#alternate_spec_based_on_ff6.0a1 >.

Re: Harmony modules feedback

now I am ... thanks for those links, requires optimizer seems already good enough as cross-platform concept br On Mon, Jan 16, 2012 at 9:01 PM, Axel Rauschmayer wrote: > @Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be > used together with almond [2], an AMD loader with

Re: A different semantics for WeakMap#get default value

One probably should separate two concerns: providing a default value vs. adding missing values to the collection. One possible signature: function get(key, default = undefined, addIfMissing = false) The above would also allow you to store `undefined` and detect missing values, by using a

Re: A different semantics for WeakMap#get default value

On Mon, Jan 16, 2012 at 12:09 PM, David Bruant wrote: > Thinking more about the current semantics, I thought that what is > currently done could be achieved a bit differently: > - > var v = wm.get(o, def); > // almost equivalent to: > var v = wm.get(o) || def; > - This is a very common se

A different semantics for WeakMap#get default value

Hi, I recently wrote some code using WeakMaps and the following pattern keeps coming over and over: - var v = wm.get(o); if(v === undefined){ v = someValue; order.set(o, v); } // now, wn has a value for o (either it already did or it's been added) // v === wm.get(o) // play with v ---

Re: Harmony modules feedback

@Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint. [1] http://requirejs.org/docs/optimization.html [2] https://github.com/jrburke/almond -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitte

Re: Block Lambdas: break and continue

Allen Wirfs-Brock January 16, 2012 9:53 AM On Jan 15, 2012, at 11:16 PM, Brendan Eich wrote: I'm not slamming the door, but I do not want to lumber block-lambdas with more complexity if the hard case is as rare as I contend. Anyway "neat" is not enough. We need an u

Re: Block Lambdas: break and continue

Allen Wirfs-Brock January 16, 2012 11:32 AM On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote: I have some angst about loss of a hunk of code running "break L" up against " with (E)\nS" where E is an _expression_ and S is a statement and the two came from a bone-fide

Re: Block Lambdas: break and continue

On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote: > With completion values as In ES1-5, not even depending on > http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be > enough to say: You're right, according to ES 5 semantics this does provide "early" as the value of th

Re: Harmony modules feedback

You are underlying my points too .. I am dealing on daily basis with highly dependent little modules and the build procedure takes care of packing everything together before deployment. However, we are using a synchronous version of require, similar to the one used in node.js but that does not sca

Re: ES6 opt-in, reloaded

Brendan Eich January 16, 2012 10:35 AM I think 3 should be stated as "Provide as many incentives for using ES6 as possible". Here "using" does not demote making Typo: s/demote/denote/ -- sorry! /be ___ es-discuss mailing lis

Re: Block Lambdas: break and continue

With completion values as In ES1-5, not even depending on http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be enough to say: foo {|| exit: { ... if (...) { "early"; break exit; }

Re: ES6 opt-in, reloaded

Andreas Rossberg January 16, 2012 8:09 AM Some of the recent discussion regarding ES6 opt-in has been rather...scary. It's es-discuss, don't be scared. Just working through a thought-experiment, however misguided in someone's view, is low-cost and needs a forum for dis

Re: Harmony modules feedback

Mark S. Miller-2 wrote: > > On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak < > medikoo+mozilla@medikoo.com> wrote: > >> rauschma wrote: >> > >> > For incrementally migrating old code bases, it would make a lot of >> sense >> > to allow ES.next modules to import AMDs and vice versa. >> > >>

Re: Harmony modules feedback

> First, there are two things you might mean by "piece of code". One is > "the source code for a library/script", which is necessarily > identified by a URL on the Web (perhaps by a filename in other > contexts, like Node). That stays as a string in every design. The > other is "a library that I

Re: Block Lambdas: break and continue

> However, block lambdas are often evaluated for a value and none of the > current continue/break based solutions include a way to provide an explicit > continuation value. Here is an idea for that: > > foo {|| >exit: { > ... > if (...) break exit with "earl

Re: Harmony modules feedback

> While I agree that ES.next modules do not need to worry about AMD if it does > not establish itself as a widely used de facto standard, I think we would all > be better off if (the core subset of) AMD did become a wild success and > ES.next felt the need to figure out how to manage the transit

Re: ES6 opt-in, reloaded

> Compared to Dave's original proposal, the only scenario on which it > loses re (1) is if the program already consists of a module, in which > case you'd still have to write the opt-in declaration. One can > probably argue whether this is worth adding an extra rule (personally, > I don't think so)

Re: Block Lambdas: break and continue

On Jan 15, 2012, at 11:16 PM, Brendan Eich wrote: > > I think you are forgetting the for(;;) loop. Paren-ful for loop: yup, I thought the "Paren-free" reference was regarding paren-free calls. Paren-free in other context does indeed create ambiguities with my suggests. I had thought that pa

Re: Harmony modules feedback

I have posted about a "better approach" to load modules too talking about an early state library that already works like a charm: http://webreflection.blogspot.com/2012/01/y-u-no-use-libraries-and-add-stuff.html AMD is good in theory but as far as I can see it fails miserably when it comes to JS p

Re: Better Native XML Support

Le 16/01/2012 18:30, Nuno Job a écrit : > Hi guys, > > I would like to make the case for better native XML support in ES5: > > This is the most commented open issue on V8: > http://code.google.com/p/v8/issues/detail?id=235 > Unfortunately people didn't agree on E4X and this makes the life of > deve

RE: ES6 opt-in, reloaded

Great summary of the goals, and I agree with the plea for starting with "opting into ES6 through one simple declaration on the top of a program (and nowhere else). Otherwise it's ES5 unchanged." #6 has other variants as well, such as copy/paste hazards and even subtler concatenation hazards, wh

Re: Harmony modules feedback

On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak < medikoo+mozilla@medikoo.com> wrote: > rauschma wrote: > > > > For incrementally migrating old code bases, it would make a lot of sense > > to allow ES.next modules to import AMDs and vice versa. > > > > -1 > > I'm not sure if I understood this c

Re: Block lambda grammar: BlockArguments

Lasse Reichstein January 16, 2012 5:54 AM I believe it's perfectly valid to write blocks (for no particularreason) without any keyword.I.e.: function foo() {  var x = 42;  {    var y = 10;    print(x+y);  }  return x; }Obviously it's useless, but it is va

Re: Question about direct proxies syncing their targets

2012/1/14 Tab Atkins Jr. > In the direct proxies proposal at > , > there's the following line: > > get: > * Invariant checks: >* if property exists on target as a data property, updates the > target’s property with the returned v

ES6 opt-in, reloaded

Some of the recent discussion regarding ES6 opt-in has been rather... scary. I would like to step back a bit, and try to identify the goals that we actually want to achieve. I think these are: 1. Make ES6 opt-in as convenient as possible. 2. Avoid reliance on external features like script tags or

Re: Harmony modules feedback

rauschma wrote: > > I think introducing new language constructs for modules is good, because > they are so fundamental. > +1 rauschma wrote: > > For incrementally migrating old code bases, it would make a lot of sense > to allow ES.next modules to import AMDs and vice versa. > -1 I'm not

Re: Block lambda grammar: BlockArguments

Lasse Reichstein wrote: On Mon, Jan 16, 2012 at 2:14 PM, Herby Vojčík wrote: Thank you, it helped. It is the fact that in ES up till now, {} block were always delimited by a {} blocks which are parts of the same control structure. I did not talk about free blocks, but about bound blocks. S

Re: Block lambda grammar: BlockArguments

On Mon, Jan 16, 2012 at 2:14 PM, Herby Vojčík wrote: > Thank you, it helped. > > It is the fact that in ES up till now, {} block were always delimited by a > keyword (if/else is probably the only case when two blocks were present). So > it is not a bad idea to retain it. I believe it's perfectly

Re: Block lambda grammar: BlockArguments

Thank you, it helped. It is the fact that in ES up till now, {} block were always delimited by a keyword (if/else is probably the only case when two blocks were present). So it is not a bad idea to retain it. The problem with this is, one can put arguments in normal parentheses as well as pa