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`
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
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
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
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.
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
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(
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
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
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
*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
11 matches
Mail list logo
