date:20190309

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Jordan Harband

There'd still have to be a way for an arbitrary function - which (unless
called in `a.b()` form) has no guaranteed connection back to `a` - to have
a reference back to the object.

On Sat, Mar 9, 2019 at 10:57 PM Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:

> How about binding `this` to a variable in the constructor? The following
> syntax throws an error due to `this` being a reserved word, so won't break
> any existing code:
>
> ```
> class Foo {
>   constructor (this: self, /* normal args */) {
> // ...
>   }
> }
> ```
>
> I can see arguments against that as it breaks the convention for how
> parameter lists work, and also requires a constructor. Perhaps, then, we
> could either use something like a modified version of class field
> declarations to make class variables:
>
> ```
> class Foo {
>   const self = this;
>   // ...
> }
> ```
>
> Or, maybe, allow parentheses before the class body to define variables:
>
> ```
> class Foo (this: self) {
>   //...
> }
> ```
>
> No, I don't like that one either.
>
> The second suggestion (class variables as extension of class fields
> proposal) seems like it has potential to me, so it seems like an excellent
> time for everyone here to tell me why it's awful and stupid.
>
> On Sun, 10 Mar 2019 at 06:59 Jordan Harband  wrote:
>
>> The engine only has that knowledge when you call it in `a.b()` form - at
>> which point, `this` is already the instance. For a keyword to not be
>> context dependent, it'd have to be the instance even when you'd done
>> something like `const { b } = a; b()`. To do this would require either a)
>> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
>> a getter that does that binding upon request.
>>
>> Constructor-binding, field-binding, or arrow function fields all work the
>> same way - they create a separate copy of a function for *each and every*
>> instance, so that the function can point back to the instance even when
>> extracted off of the object.
>>
>> I'm not clear on how there'd be any other way to do it.
>>
>> On Sat, Mar 9, 2019 at 1:41 PM john larson 
>> wrote:
>>
>>> Although the method lives on the prototype, the engine should already
>>> have knowledge of the object whose method is being invoked. I am not an
>>> expert on the internal workings of the engine, so I would be glad if anyone
>>> would correct me on this if I am wrong.
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_4773041203224270933_m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband 
>>> wrote:
>>>
 An additional keyword like this would require a function to have a
 hidden reference back to the instance. However, especially for `class`
 methods, but also for ES5-style inheritance, or even for `class Foo {}
 Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
 billion instances, but only one function that uses your new keyword - how
 would the engine know which instance you were referring to?

 On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:

> Hi John,
>
> > I believe that it would be a trivial task for
> > current static code analyzers to restrict usage of "this" for anyone
> > opting in to use this new keyword exclusively.
>
> Static tooling, like the TypeScript compiler, can detect problematic
> method usage already today. Sure, having a dedicated syntax for this
> will make static analysis simpler, but I don't deem that a worthy
> addition to the language.
>
> > As you mentioned, arrow functions might have their own
> > problems. Wouldn't such an alternative keyword be a good addition to
> our
> > toolkit anyway?
>
> What I was trying to say is that your proposed alternative has exactly
> the same problems as instance-member arrow functions have today.
>
> Best regards,
>   Bergi
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
 ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Michael Luder-Rosefield

How about binding `this` to a variable in the constructor? The following
syntax throws an error due to `this` being a reserved word, so won't break
any existing code:

```
class Foo {
  constructor (this: self, /* normal args */) {
// ...
  }
}
```

I can see arguments against that as it breaks the convention for how
parameter lists work, and also requires a constructor. Perhaps, then, we
could either use something like a modified version of class field
declarations to make class variables:

```
class Foo {
  const self = this;
  // ...
}
```

Or, maybe, allow parentheses before the class body to define variables:

```
class Foo (this: self) {
  //...
}
```

No, I don't like that one either.

The second suggestion (class variables as extension of class fields
proposal) seems like it has potential to me, so it seems like an excellent
time for everyone here to tell me why it's awful and stupid.

On Sun, 10 Mar 2019 at 06:59 Jordan Harband  wrote:

> The engine only has that knowledge when you call it in `a.b()` form - at
> which point, `this` is already the instance. For a keyword to not be
> context dependent, it'd have to be the instance even when you'd done
> something like `const { b } = a; b()`. To do this would require either a)
> `a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
> a getter that does that binding upon request.
>
> Constructor-binding, field-binding, or arrow function fields all work the
> same way - they create a separate copy of a function for *each and every*
> instance, so that the function can point back to the instance even when
> extracted off of the object.
>
> I'm not clear on how there'd be any other way to do it.
>
> On Sat, Mar 9, 2019 at 1:41 PM john larson 
> wrote:
>
>> Although the method lives on the prototype, the engine should already
>> have knowledge of the object whose method is being invoked. I am not an
>> expert on the internal workings of the engine, so I would be glad if anyone
>> would correct me on this if I am wrong.
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:
>>
>>> An additional keyword like this would require a function to have a
>>> hidden reference back to the instance. However, especially for `class`
>>> methods, but also for ES5-style inheritance, or even for `class Foo {}
>>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>>> billion instances, but only one function that uses your new keyword - how
>>> would the engine know which instance you were referring to?
>>>
>>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>>
 Hi John,

 > I believe that it would be a trivial task for
 > current static code analyzers to restrict usage of "this" for anyone
 > opting in to use this new keyword exclusively.

 Static tooling, like the TypeScript compiler, can detect problematic
 method usage already today. Sure, having a dedicated syntax for this
 will make static analysis simpler, but I don't deem that a worthy
 addition to the language.

 > As you mentioned, arrow functions might have their own
 > problems. Wouldn't such an alternative keyword be a good addition to
 our
 > toolkit anyway?

 What I was trying to say is that your proposed alternative has exactly
 the same problems as instance-member arrow functions have today.

 Best regards,
   Bergi
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

>>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Tagged Constructor & Taggable Function/Map/Set constructor

2019-03-09 Thread Sm In

Template literal(includes tagged template) is so strong feature.
It makes it possible to add elegant DSL for Library(or maybe framework)
which also can interact with js.([styled-component proofed this with their
api](https://www.styled-components.com/))
Why don't we use them to enhance ECMAScript's API?

If we allow using tagged template to constructors just like this:

```js
new Constructor`
  blahlah
`; // what about to call this syntax as tagged constructor?
```

we can do something like this:

 If `Function` construcor is taggable

```js
const sum = new Function`
  (a, b) {
return a + b;
  }
`;
```

 If `Map` constructor is taggable

```js
new Map`
   a: 1234,
   one: ${() => 1},
   str: 'Hello!',
   bool: true
`;
```

 If `Set` constructor is taggable. and It supports list comprehension

```js
new Set`
  ${range}
-> ${x => x * 2}
-> ${x => x < 10}
`; // Set [2, 4, 6, 8]
```

Feedback is welcome!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Jordan Harband

The engine only has that knowledge when you call it in `a.b()` form - at
which point, `this` is already the instance. For a keyword to not be
context dependent, it'd have to be the instance even when you'd done
something like `const { b } = a; b()`. To do this would require either a)
`a` has its own distinct copy of `b` that's bound to `a`, or b) `a.b` to be
a getter that does that binding upon request.

Constructor-binding, field-binding, or arrow function fields all work the
same way - they create a separate copy of a function for *each and every*
instance, so that the function can point back to the instance even when
extracted off of the object.

I'm not clear on how there'd be any other way to do it.

On Sat, Mar 9, 2019 at 1:41 PM john larson  wrote:

> Although the method lives on the prototype, the engine should already have
> knowledge of the object whose method is being invoked. I am not an expert
> on the internal workings of the engine, so I would be glad if anyone would
> correct me on this if I am wrong.
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:
>
>> An additional keyword like this would require a function to have a hidden
>> reference back to the instance. However, especially for `class` methods,
>> but also for ES5-style inheritance, or even for `class Foo {}
>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
>> billion instances, but only one function that uses your new keyword - how
>> would the engine know which instance you were referring to?
>>
>> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>>
>>> Hi John,
>>>
>>> > I believe that it would be a trivial task for
>>> > current static code analyzers to restrict usage of "this" for anyone
>>> > opting in to use this new keyword exclusively.
>>>
>>> Static tooling, like the TypeScript compiler, can detect problematic
>>> method usage already today. Sure, having a dedicated syntax for this
>>> will make static analysis simpler, but I don't deem that a worthy
>>> addition to the language.
>>>
>>> > As you mentioned, arrow functions might have their own
>>> > problems. Wouldn't such an alternative keyword be a good addition to
>>> our
>>> > toolkit anyway?
>>>
>>> What I was trying to say is that your proposed alternative has exactly
>>> the same problems as instance-member arrow functions have today.
>>>
>>> Best regards,
>>>   Bergi
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread john larson

Although the method lives on the prototype, the engine should already have
knowledge of the object whose method is being invoked. I am not an expert
on the internal workings of the engine, so I would be glad if anyone would
correct me on this if I am wrong.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband  wrote:

> An additional keyword like this would require a function to have a hidden
> reference back to the instance. However, especially for `class` methods,
> but also for ES5-style inheritance, or even for `class Foo {}
> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
> billion instances, but only one function that uses your new keyword - how
> would the engine know which instance you were referring to?
>
> On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:
>
>> Hi John,
>>
>> > I believe that it would be a trivial task for
>> > current static code analyzers to restrict usage of "this" for anyone
>> > opting in to use this new keyword exclusively.
>>
>> Static tooling, like the TypeScript compiler, can detect problematic
>> method usage already today. Sure, having a dedicated syntax for this
>> will make static analysis simpler, but I don't deem that a worthy
>> addition to the language.
>>
>> > As you mentioned, arrow functions might have their own
>> > problems. Wouldn't such an alternative keyword be a good addition to our
>> > toolkit anyway?
>>
>> What I was trying to say is that your proposed alternative has exactly
>> the same problems as instance-member arrow functions have today.
>>
>> Best regards,
>>   Bergi
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Jordan Harband

An additional keyword like this would require a function to have a hidden
reference back to the instance. However, especially for `class` methods,
but also for ES5-style inheritance, or even for `class Foo {}
Foo.prototype.bar = function () {}`, methods are *shared*. You might have a
billion instances, but only one function that uses your new keyword - how
would the engine know which instance you were referring to?

On Sat, Mar 9, 2019 at 7:50 AM Bergi  wrote:

> Hi John,
>
> > I believe that it would be a trivial task for
> > current static code analyzers to restrict usage of "this" for anyone
> > opting in to use this new keyword exclusively.
>
> Static tooling, like the TypeScript compiler, can detect problematic
> method usage already today. Sure, having a dedicated syntax for this
> will make static analysis simpler, but I don't deem that a worthy
> addition to the language.
>
> > As you mentioned, arrow functions might have their own
> > problems. Wouldn't such an alternative keyword be a good addition to our
> > toolkit anyway?
>
> What I was trying to say is that your proposed alternative has exactly
> the same problems as instance-member arrow functions have today.
>
> Best regards,
>   Bergi
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

2019-03-09 Thread Felipe Nascimento de Moura

Personally, I don't think it would be THAT useful...
but...I think there is something behind this proposal that makes sense.

I do believe it could be useful for developers to have an easier access to
number parts or characteristics.
Perhaps something like:

const i = 1234.567;

console.log( i.float ); // 567
console.log( i.abs ); // 1234
console.log( i.thousands ); // 1
console.log( i.million ); // 0
console.log( i.hundred ); // 2
console.log( i.hundreds ); // 12
console.log( i.ten ); // 2
console.log( i.tens ); // 123
console.log( i.tenth ); // 5
console.log( i.tenths ); // 5
console.log( i.hundredth ); // 6
console.log( i.hundredth ); // 56

There is this table with some patterns:
Large Numbers
*Number* *Name* *Symbol* *Description (Short
Scale)* Description
(Long Scale)
1,000,000,000,000,000,000,000,000 yotta Y Septillion Quadrillion
1,000,000,000,000,000,000,000 zetta Z Sextillion Thousand Trillion/Trilliard
1,000,000,000,000,000,000 exa E Quintillion Trillion
1,000,000,000,000,000 peta P Quadrillion Thousand Billion/Billiard
1,000,000,000,000 tera T Trillion Billion
1,000,000,000 giga G Billion Thousand Million/Milliard
1,000,000 mega M Million Million
1,000 kilo k Thousand Thousand
100 hecto h Hundred Hundred
10 deca da Ten Ten>Small Numbers
*Number* *Name* *Symbol* *Description (Short
Scale)* *Description
(Long Scale)*
0.1 deci d Tenth Tenth
0.01 centi c Hundredth Hundredth
0.001 milli m Thousandth Thousandth
0.000 001 micro u Millionth Millionth
0.000 000 001 nano n Billionth Thousand Millionth
0.000 000 000 001 pico p Trillionth Billionth
0.000 000 000 000 001 femto f Quadrillionth Thousand Billionth
0.000 000 000 000 000 001 atto a Quitillionth Trillionth
0.000 000 000 000 000 000 001 zepto z Sextillionth Thousand Trillionth
0.000 000 000 000 000 000 000 001 yocto y Septillionth Quadrillionth
I mean...something like that could make sense to offer faster access to
parts of numbers...

- Could be useful for games, statics, animations, transitions, etc
- Very useful to deal with the recently added bigInt
- The implementation of something like this is not trivial, and there must
be many different ways to accomplish similar results, what increases the
granularization of implementations in different libs
- I don't think this would bring trouble to current language implementation

Just adding my 2 cents to the discussion :)

[ ]s

*--*

*Felipe N. Moura*
Web Developer, Google Developer Expert
, Founder of
BrazilJS  and Nasc .

Website:  http://felipenmoura.com / http://nasc.io/
Twitter:@felipenmoura 
Facebook: http://fb.com/felipenmoura
LinkedIn: http://goo.gl/qGmq
-
*Changing  the  world*  is the least I expect from  myself!

On Fri, Mar 8, 2019 at 2:38 PM Naveen Chawla  wrote:

> I've probably missed it, but what application are you building that would
> use this feature? Or, under what circumstances would an application use
> this feature?
>
> On Fri, 8 Mar 2019 at 17:24 guest271314  wrote:
>
>> The code for "transforming" numeric values to array and array to numeric
>> value has at least one complete implementation. That is not the goal of
>> this proposal.
>>
>> The goal of this proposal is to suggest to this body to take up the task
>> of defining the various manners in which that transformation can be
>> achieved, as illustrated at the example for the number *e* at
>> https://esdiscuss.org/topic/fwd-proposal-1-number-integer-or-decimal-to-array-2-array-to-number-integer-or-decimal#content-21
>> .
>>
>> From perspective here, the third example provides the output (in array
>> representation) which can be manipulated more extensively than the previous
>> two examples.
>>
>> [2, .718281828459045] // example 1
>>
>> [2.7, 18281828459045] // example 2
>>
>> [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9] // example 3
>>
>>
>> How should those three examples be named for disambiguation as to the
>> output?
>>
>> If this body does decide to take up the matter of actually defining
>> Number and/or Math, and Array methods to perform the conversions, it would
>> be helpful if each of the three (and potentially more) possible outputs
>> have a clearly defined name for that output.
>>
>> AFAIK, there is no prior art relevant to conversion or "transforming"
>> JavaScript numeric values to array and array to numeric values.
>>
>> Does the above make sense to you relevant to the purpose of this proposal
>> and what this proposal actually suggests?
>>
>> On Fri, Mar 8, 2019 at 4:45 PM Jeremy Martin  wrote:
>>
>>> Is it fair to suggest that transforming numeric values to and from
>>> arrays isn't the ultimate goal of this proposal? Based on your examples, it
>>> seems there are specific manipulations you would like to be able to perform
>>> to numeric values, and your contention is that these manipulations would

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Bergi


Hi John,


I believe that it would be a trivial task for
current static code analyzers to restrict usage of "this" for anyone
opting in to use this new keyword exclusively.


Static tooling, like the TypeScript compiler, can detect problematic
method usage already today. Sure, having a dedicated syntax for this
will make static analysis simpler, but I don't deem that a worthy
addition to the language.


As you mentioned, arrow functions might have their own
problems. Wouldn't such an alternative keyword be a good addition to our
toolkit anyway?


What I was trying to say is that your proposed alternative has exactly
the same problems as instance-member arrow functions have today.

Best regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread john larson

Hi Bergi,

Thanks for your input. I believe that it would be a trivial task for
current static code analyzers to restrict usage of "this" for anyone opting
in to use this new keyword exclusively. But the same does not hold true for
other work-arounds such as arrow functions. And in addition to that, as you
mentioned, arrow functions might have their own problems. Wouldn't such an
alternative keyword be a good addition to our toolkit anyway?

Best Regards,
John

Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Mar 9, 2019 at 5:18 PM Bergi  wrote:

> Hi John,
> I don't think we do need another keyword for this. People would forget
> to use that new keyword instead of using this, just like they currently
> forget to use arrow functions.
> That said, your desired "behind-the-scenes implementation" can already
> be achieved easily with the class fields proposal and an arrow function.
> However, [there are many problems with that
> approach](
> https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1
> )
> anyway.
>
> kind regards,
>   Bergi
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread Bergi


Hi John,
I don't think we do need another keyword for this. People would forget
to use that new keyword instead of using this, just like they currently
forget to use arrow functions.
That said, your desired "behind-the-scenes implementation" can already
be achieved easily with the class fields proposal and an arrow function.
However, [there are many problems with that
approach](https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1)
anyway.

kind regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal For A New Alternative Keyword To “this” For Classes

2019-03-09 Thread john larson

*Summary of the problem:*

“this” keyword in Javascript is context dependent. And this is one of the
culprits of most subtle and latent errors in Javascript. Moreover, use of
“this” cannot be avoided if we are using classes and trying to reference
instance properties.

When “this” is used in callback functions or in functions given
to forEach as argument, IDEs rightfully cannot raise any design-time
errors, giving developers the false sense of security, but we get run-time
errors because “this” is undefined.

There seem to be two work-arounds:

1.  Using arrow functions

2.  Using .bind(this) syntax

Just assuming we forgot to use an arrow function or a .bind(), the IDE will
not be able to raise an error and we will encounter the error in run-time.



*What I propose:*

I am proposing a new keyword that will be the alternative of "this" and
will always point to the instance of the class. The name of the new keyword
can be chosen with consensus from the community such that it would
minimize/eliminate collision in existing codebases.



Here is a sample js code:



class RequestManager{



constructor(){

this.successMessage = "Xhr successful.";

}





makeRequest() {

var oReq = new XMLHttpRequest();

oReq.addEventListener("load", this.responseHandler);

oReq.open("GET", "www.google.com");

oReq.send();

}



responseHandler() {

window.alert(this.successMessage);

}

}



var reqManager = new RequestManager();

reqManager.makeRequest();



This piece of code will alert “undefined” because “this” is undefined in
the callback function in strict mode.

Now let’s assume a new keyword is used insetead of “this” that will always
point to the class instance.

As per its implementation, as described on
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes:

*“JavaScript classes, introduced in ECMAScript 2015, are primarily
syntactical sugar over JavaScript's existing prototype-based inheritance.
The class syntax does not introduce a new object-oriented inheritance model
to JavaScript.”*

So with the new keyword introduced, behind the scenes, previous class could
be interpreted as a piece of code along the lines of:



var RequestManager = function () {

var self = this;

self.successMessage = "Xhr successful";



self.makeRequest = function () {

var oReq = new XMLHttpRequest();

oReq.addEventListener("load", responseHandler);

oReq.open("GET", "www.google.com");

oReq.send();

};



var responseHandler = function () {

window.alert(self.successMessage);

};

};

var reqManager = new RequestManager();



reqManager.makeRequest();



I believe this way, we would not have to resort to work-arounds for such a
fundamental construct of the language and this would ease developers’ lives
as someone forgetting to have used an arrow function or the .bind(this)
syntax will not be a problem anymore.



Best Regards,

John


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal For A New Alternative Keyword To “this” For Classes

Proposal: Tagged Constructor & Taggable Function/Map/Set constructor

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal For A New Alternative Keyword To “this” For Classes

Re: Proposal For A New Alternative Keyword To “this” For Classes

Proposal For A New Alternative Keyword To “this” For Classes

11 matches

Site Navigation

Mail list logo

Footer information