Re: Coordination (was: ES6 Modules)

> > > Put concretely: if Futures are provided via libraries, but you can't > assume (require) libraries, then you can't design DOM APIs around Futures. > Clearly, one way to solve this is put Futures into the language, but > another is to solve the extensibility problem so you can start requiring >

Re: Coordination

On Sat, Apr 13, 2013 at 12:41 PM, Anne van Kesteren wrote: > Apologies for the ambiguity. I meant pushing for an "API idiomacy > review" process. I've just asked for the same in Blink: . (I'll definitely be

Re: Coordination

But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and

Re: Coordination (was: ES6 Modules)

On Sat, Apr 13, 2013 at 12:52 PM, Sam Tobin-Hochstadt wrote: > On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke wrote: > >> As far as "outreach", in my own experience whenever I've offered > feedback > >> directly to DOM API authors, I'm frequently met with responses such as > >> "that's not consiste

Re: Coordination (was: ES6 Modules)

On Sat, Apr 13, 2013 at 8:52 PM, Sam Tobin-Hochstadt wrote: > I don't understand what you're saying here. Is it just that JS doesn't > have a module system yet? What else has TC39 failed to provide? > > Also, by definition, there's nothing available to library authors that > isn't available to pl

Re: Coordination (was: ES6 Modules)

On Sat, Apr 13, 2013 at 3:12 PM, Dirk Pranke wrote: >> As far as "outreach", in my own experience whenever I've offered feedback >> directly to DOM API authors, I'm frequently met with responses such as >> "that's not consistent with the platform [/end]". >> >>> >>> 3) TC39 et al. need to give us

Re: Coordination

Anne van Kesteren wrote: Apologies for the ambiguity. I meant pushing for an "API idiomacy review" process. Thanks -- on that front, recent API work (DAP, WebApps, SysApps) has been about par for the course, from what I've seen. In other words, a mixed bag ranging from nicely-idiomatic or goo

Re: Coordination

On Sat, Apr 13, 2013 at 7:14 PM, Brendan Eich wrote: > Anney: we *did* submit drafts for all APIs needed for Firefox OS. See the > lists compiled at > > http://brendaneich.com/2012/02/mobile-web-api-evolution/ (2012, based on > work starting in fall 2011 well before anything "shipped") > > and > >

Re: Coordination (was: ES6 Modules)

On Fri, Apr 12, 2013 at 9:49 PM, Rick Waldron wrote: > > > > On Fri, Apr 12, 2013 at 10:17 PM, Dirk Pranke wrote: > >> On Fri, Apr 12, 2013 at 8:06 AM, Anne van Kesteren wrote: >> >>> On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron >>> wrote: >>> > The "DOM side" should all be subscribed to es-disc

Re: What are Symbols? Objects? New primitive type?

Claude Pache wrote: Therefore, I think we should make a rule: `new Primitive` should throw for primitive types That's the plan for new value objects, e.g. int64 and uint64. Further, for aggregates created by binary data (structs and typed arrays) we have emerging consensus that new T(...) ma

Re: Outreach? (was Coordination/ES6 Modules)

On Fri, Apr 12, 2013 at 9:36 PM, Rick Waldron wrote: > > cc es-discuss. > > > On Fri, Apr 12, 2013 at 10:37 PM, Dirk Pranke wrote: > >> One takeaway I have from both my own recent efforts to understand the >> state of ES6 and the recent threads on es-discuss and public-script-coord >> is that I th

Re: Coordination

Brendan Eich wrote: Anney (Sorry for the typo!) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Coordination

Anne van Kesteren wrote: If we want a useful "API idiomacy review" process, this process has to start > at a time it's still possible to change the API. One solution is for all > vendors to submit an API to the W3C (or at least public-script-coord) > *before* shipping it. I'm doubtful this wi

Re: What are Symbols? Objects? New primitive type?

'new Number' and 'new String' are also functionally useful to a degree - I've had reason to use both in my compiler's runtime library, either to allow returning a value from a constructor or to assign properties to a number. It sounds like 'new Symbol' will never be functionally useful because it

Re: What are Symbols? Objects? New primitive type?

Le 13 avr. 2013 à 15:25, Andreas Rossberg a écrit : > On 13 April 2013 13:36, Claude Pache wrote: >> >> >> Le 13 avr. 2013 à 09:56, Andreas Rossberg a écrit : >> >>> On 13 April 2013 00:35, Allen Wirfs-Brock wrote: Regarding #3 The biggest footgun is if ne

Re: What are Symbols? Objects? New primitive type?

On 4/13/2013 12:31 AM, Andreas Rossberg wrote: On 13 April 2013 00:12, Brandon Benvie wrote: 3.) A new type of primitive along with a new type of wrapper. In this case we use the String/Number/Boolean precedent where `Symbol()` and `new Symbol()` produce different kinds of results. The problem

Re: What are Symbols? Objects? New primitive type?

On 13 April 2013 13:36, Claude Pache wrote: > > > Le 13 avr. 2013 à 09:56, Andreas Rossberg a écrit : > >> On 13 April 2013 00:35, Allen Wirfs-Brock wrote: >>> >>> >>> Regarding #3 >>> >>> The biggest footgun is if >>> new Symbol() >>> creates a Symbol wrapper. However, >>> new Symbol() >>>

Re: What are Symbols? Objects? New primitive type?

Le 13 avr. 2013 à 09:56, Andreas Rossberg a écrit : > On 13 April 2013 00:35, Allen Wirfs-Brock wrote: >> >> >> Regarding #3 >> >> The biggest footgun is if >> new Symbol() >> creates a Symbol wrapper. However, >> new Symbol() >> returning a primitive values would be unlike anything we c

Re: A Precedent

Le 13/04/2013 03:31, Andrea Giammarchi a écrit : Do you read internet where every developer calls __proto__ ugly ? I do read the Internet [1]. I believe Brendan and all TC39 do too. Let's be super careful when using "every"/"all"/"no"/"none"/"always"/"never" and other superlatives. History ha

Re: Coordination

On Sat, Apr 13, 2013 at 11:35 AM, David Bruant wrote: > I've also sent my share of API feedback and been met with sometimes no > responses at all which I personally interpreted as "it's shipped or close > enough to; it's too late to make an API change now". Of course, that's my > interpretation :-

Re: Coordination

Le 12/04/2013 14:10, Alex Russell a écrit : From the DOM side, I don't know that there's enough F2F contact to say that "DOM authors need to be aware of X" from the TC39 side will ever fly without some big checkbox in their lifecycle that says "has been reviewed for idomatic API practice [yes|n

Re: What are Symbols? Objects? New primitive type?

On 13 April 2013 00:35, Allen Wirfs-Brock wrote: > there were lots of additional subtle points brought up on the twitter > threads > > Regarding #1 > This is how it was spec. until the last TC39 meeting. > > Some implementers think this will be easiest to implement. Hm, judging from the most rec

Re: What are Symbols? Objects? New primitive type?

On 13 April 2013 00:12, Brandon Benvie wrote: > 3.) A new type of primitive along with a new type of wrapper. In this case > we use the String/Number/Boolean precedent where `Symbol()` and `new > Symbol()` produce different kinds of results. The problem here is the > confusion that comes with ToSt