Re: System global

I see, thanks Le mer. 8 avr. 2015 à 20:55, Caitlin Potter a écrit : > Loader was moved to http://whatwg.github.io/loader/ — I believe the > System global was done away with entirely, and probably won’t make a > return. I could be wrong, though. > > On Apr 8, 2015, at 2:43 PM, Maël Nison wrote:

RE: the Great Tooling Revolution

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] > However, that is a lot of infrastructure work and I don’t think we should let >it to get in the way of shipping our first yearly update. Thanks for pointing this out. I agree that we may be over-optimistic in thinking the new tooling wil

Re: the Great Tooling Revolution

> On Apr 8, 2015, at 12:19 PM, Domenic Denicola wrote: > > This was discussed briefly at the previous meeting, perhaps un-minuted. > > The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and > [Ecmarkdown][]. It will take pull requests, have a master branch that you can > view

Re: System global

Loader was moved to http://whatwg.github.io/loader/ — I believe the System global was done away with entirely, and probably won’t make a return. I could be wrong, though. > On Apr 8, 2015, at 2:43 PM, Maël Nison wrote: > > Hi, > > Is the System global still o

System global

Hi, Is the System global still on the ES6 roadmap ? I can't find any reference to it on the draft[1] (same with the Loader class). I was especially wondering how to define a module manually. SystemJS has something like `System.set`, but I was wondering where it was actually described in the spec.

RE: the Great Tooling Revolution

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michael Dyck > So not as git branches of the spec? I mean, I guess they could if they want, but that seems like a lot of work for the spec writer to be constantly rebasing. Better to only do the branch when it's time for a p

Re: the Great Tooling Revolution

Michael Dyck wrote: Unlike the current process, the post-ES2015 spec process requires two shipping implementations before a feature is integrated into the spec. While we're waiting for that, we anticipate proposal documents to prepare for integration by being written as Ecmarkup/Ecmarkdown spec d

Re: loop unrolling and completion values in ES6

Allen Wirfs-Brock wrote: Well, they do for normal loop completions (according to the spec.) but not for breaks. I this the latter is a bug. In particular, I think it is pretty obvious that: eval(“ {0; while (true) {1; break}; 2}”) (single quotes might avoid the smart-dumb transformation

Re: the Great Tooling Revolution

On 15-04-08 12:19 PM, Domenic Denicola wrote: This was discussed briefly at the previous meeting, perhaps un-minuted. The meeting notes for Jan 29th have a section where ecmarkup/down is introduced and discussed somewhat, but there's no decision regarding its use. The basic plan is to develop

RE: the Great Tooling Revolution

This was discussed briefly at the previous meeting, perhaps un-minuted. The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and [Ecmarkdown][]. It will take pull requests, have a master branch that you can view (and implementers should view, to see any bug fixes made since the Ec

Re: loop unrolling and completion values in ES6

> On Apr 7, 2015, at 10:09 AM, Alan Schmitt > wrote: > > Hi Allen, > > On 2015-04-06 02:08, Allen Wirfs-Brock writes: > >> Alan, >> >> I freed up a couple minutes for a quick look at this. I want to spend some >> more time look at it deeper as this is an area where I made some fixes just >>

Re: Existential Operator / Null Propagation Operator

> Le 7 avr. 2015 à 21:09, Herby Vojčík a écrit : > > > > Kevin Smith wrote: >> >> > Plus, it can be used for "normalizing" null/undefined to undefined: >> > >> > var normalizedFoo = ?foo; >> > >> > Seems sort of nice that it is separated and there are no special >> operations for ?., ?(, ?[.

Re: Existential Operator / Null Propagation Operator

The prefix `?` for an absorbing Nil value sounds good. The semantics of `delete` may need clarifying; what should the following construct do? `delete ?a.b.c` Most intuitive would be to not raise an error and return true if either the `b` or `c` properties are missing, whether or not in strict mo

Re: Existential Operator / Null Propagation Operator

On 7 April 2015 at 18:33, Christoph Pojer wrote: > it doesn't have to be a bug. It asserts that if a is not > null/undefined, it must have a property b. This can be enforced > through static typing. Under option 1, that's not what it does. Since it's equivalent to `(a?.b).c`, if a is null/undef