Re: Lexical scope while extending prototype?

On Mon, Feb 10, 2014 at 10:13 PM, Allen Wirfs-Brock wrote: > Object.assign(String.prototype, { > repeat(n) {return Array(+n+1).join(this)} > }); > Roger that! -- *'I am what I am because of who we all are'* h3manth.com *-- Hemanth HM * _

Re: comment overflow

On 14-02-10 11:53 AM, Allen Wirfs-Brock wrote: sure, add the complete list to bug 2428 Done! Thanks for all the great reports, You're welcome. It's nice to hear they're appreciated. -Michael ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: The case for modular Loader.

On Mon, Feb 10, 2014 at 11:24 AM, Erik Arvidsson wrote: > I also find the mutation of System.normalize slightly worrisome but I do > believe that good programming practice here would mean that you would call > the previous version of it after your changes. Mostly like a pre-advice. > > { > let l

Re: The case for modular Loader.

On Feb 10, 2014, at 8:55 AM, John Barton wrote: > Indeed, however, this herring is only red on one fin: the mutability of > System is not limited to the registry and in fact every aspect of the System > is mutable. As far as I can tell, a mutation to say normalize or locate is > entirely unpre

Re: comment overflow

On Feb 10, 2014, at 11:20 AM, Michael Dyck wrote: > On 14-02-10 08:37 AM, Allen Wirfs-Brock wrote: >> I'd suggest grouping all minor editorial bugs by chapter. That's how >> I'll process them. > > So, just to be clear, a "chapter" is what the spec itself (usually) calls a > "clause"? (I.e., the

Re: The case for modular Loader.

Should have been System.normalize etc. On Mon Feb 10 2014 at 2:24:19 PM, Erik Arvidsson wrote: > I also find the mutation of System.normalize slightly worrisome but I do > believe that good programming practice here would mean that you would call > the previous version of it after your changes.

Re: The case for modular Loader.

I also find the mutation of System.normalize slightly worrisome but I do believe that good programming practice here would mean that you would call the previous version of it after your changes. Mostly like a pre-advice. { let locate = System.locate; System.locate = function(...) { if (som

Re: comment overflow

On 14-02-10 08:37 AM, Allen Wirfs-Brock wrote: I'd suggest grouping all minor editorial bugs by chapter. That's how I'll process them. So, just to be clear, a "chapter" is what the spec itself (usually) calls a "clause"? (I.e., the main body of the spec has 26 of them.) If so, that means I'll

Re: The case for modular Loader.

On Mon, Feb 10, 2014 at 8:32 AM, David Herman wrote: > On Feb 7, 2014, at 8:06 AM, John Barton wrote: > > > The first goal listed for ecmascript modules: > > • Obviate need for globals > > (http://wiki.ecmascript.org/doku.php?id=harmony:modules). > > Ironically, the current proposal for mo

Re: Lexical scope while extending prototype?

On Feb 10, 2014, at 5:17 AM, Hemanth H.M wrote: > So to finalize: There is no way to do this with fat arrow, rather fat arrow > is not meant for this? > > correct. As an altrnative use a concise method: Object.assign(String.prototype, { repeat(n) {return Array(+n+1).join(this)} });

Re: comment overflow

I'd suggest grouping all minor editorial bugs by chapter. That's how I'll process them. As noted in the release notes, Rev 22 is particularly rough WRT algorithm formatting because of some technical issues I was still working through. Don't bother reporting those sorts of issues for this revi

Re: The case for modular Loader.

On Feb 7, 2014, at 8:06 AM, John Barton wrote: > The first goal listed for ecmascript modules: > • Obviate need for globals > (http://wiki.ecmascript.org/doku.php?id=harmony:modules). > Ironically, the current proposal for module loading includes a global > "System" and possibly "Loader".

Re: Lexical scope while extending prototype?

So to finalize: There is no way to do this with fat arrow, rather fat arrow is not meant for this? On Feb 10, 2014 6:38 PM, "Claude Pache" wrote: > > Le 10 févr. 2014 à 09:53, Hemanth H.M a écrit : > > I do understand Arrow functions are like built-in functions in that both > lack .prototype and

Re: Lexical scope while extending prototype?

Le 10 févr. 2014 à 09:53, Hemanth H.M a écrit : > I do understand Arrow functions are like built-in functions in that both lack > .prototype and any [[Construct]] internal method It is not the main feature of arrow-functions. The essential difference between arrow- and non-arrow-function, is

Re: SubTyping Promise?

On 8 February 2014 21:43, Allen Wirfs-Brock wrote: > Yes, but it also depends upon Promise[Symbol.create] being implemented. Right. V8 has not yet implemented @@create yet (and it will likely take some time until it does, since it's a rather intrusive feature). /Andreas _

Re: comment overflow

On 10 Feb 2014, at 10:30, Michael Dyck wrote: > On a more meta level, do the process plans for ES7 include any new > mechanisms for: > (a) submitting comments on spec drafts, or > (b) reducing the number of errors in spec drafts to begin with? If only the spec were maintained in a plain text-bas

Re: Lexical scope while extending prototype?

Heh heh the second case was enlightening. If I need to bind it to prototype's context, it's not possible because it's lexical, but how does one extend prototype chain with fat arrow functions? On Mon, Feb 10, 2014 at 2:41 PM, Alex Kocharin wrote: > > In the first case "this" is window, becaus

comment overflow

I've more-or-less finished composing my comments on rev22, and I find that, even after eliminating comments that have already been made, I'm still left with about 280. Now, there's no way I'm going to create 280 bugs at bugs.ecmascript.org. I'd go crazy with all the copying and pasting. Even if I

Re: Lexical scope while extending prototype?

 In the first case "this" is window, because it's inherited from whatever scope you call it. For example, in this case it won't be window:!function() { ((n) => console.log(this))() }.call({foo: 'bar'}) In the second case "this" is window as well. But second case won't get executed, because you're r

Lexical scope while extending prototype?

I do understand Arrow functions are like built-in functions in that both lack .prototype and any [[Construct]] internal method. But why does the scope refer to the global in case of : ``` String.prototype.repeat = (n) => Array(+n+1).join(this); "ES6 ".repeat(3); // will result in "[object Windo