I'm getting deja vu again
On Tue, 19 Mar 2019 at 14:31 Isiah Meadows wrote:
> UX workflows aren't all of JS. Classes exist for many more reasons than
> that, and 99% of my classes are for abstracting non-trivial business logic
> and ensuring *those* are easily testable, not directly UI/UX.
>
>
UX workflows aren't all of JS. Classes exist for many more reasons than
that, and 99% of my classes are for abstracting non-trivial business logic
and ensuring *those* are easily testable, not directly UI/UX.
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Sun, Mar 17,
Assuming Babel can get ahold of unmodified builtins, even if it's only
during `@babel/runtime` initialization, it could still break that wrapper.
`core-js` itself uses this trick extensively to dodge otherwise observable
side effects in all of its wrappers.
(Babel *might* be invoking
```class RequestManager {
__THIS__(method) {
return new Proxy(method, {
apply: (target, thisArg, argumentsList) => {
return method.apply(thisArg, [...argumentsList, {
THIS: this
}])
}
})
}
constructor() {
this.successMessage = "Xhr
@Isiah Remember, the class-fields proposal has absorbed the private-fields
proposal, and it is those private fields that have no precise equivalent.
WeakMap and closures can approximate what private fields do. However,
private fields has semantics and capabilities that cannot be fully
reproduced
@Ranando Minor nit: class fields can be purely implemented in terms of
`defineProperty` (for public) and weak maps (for private - what's used
today for private data). Private methods could be implemented in terms of
weak sets/maps and an object with methods outside the class's scope.
Private
@John May I suggest you play around a little with Lua? That language is
prototype-based like JS, with several similar idioms, but it's a lot
simpler, without `new`, property descriptors, or the like. Like JS, it also
has a keyword `self` equivalent to JS `this` and inheritance is purely
I get what you're after. I touched on the same things when creating my
private members proposal. The best of approaches for what you want is
indeed relying on the lexical scope to act as a binding for all class
members. There's just a couple of problems with doing things that way:
1. ES is a
So in terms of implementation, may be having instance method/property
references on the objects and having static method/property references on
the prototype is the solution?
On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows
wrote:
> I've done a little engine work, and inline caches work by inline
I've done a little engine work, and inline caches work by inline type maps
based on the callee site. This *can* be used to reconstruct values +
receivers, but only when the value is constant. It is not sufficient to
ensure identity remains the same, and engines would still need a weak map
to link
Hi John!
I think the js run-time already has that information at hand, so as
long as we don't implement this as pure syntactical sugar, there would
not be a need to keep an extra reference to anything, because it would
be already there. The run-time will know which instance the invoked
method
Whatever the implementation, I'd be surprised to learn that the browser
*does* have the information automatically and wouldn't need to store
additional memory similar to .bind().
But I'm also not a browser engine expert, so there's that.
Le lun. 11 mars 2019 11 h 55, john larson a
écrit :
>
Well, actually this is the same discussion we had with *@Jordan Harband. *I
think the js run-time already has that information at hand, so as long as
we don't implement this as pure syntactical sugar, there would not be a
need to keep an extra reference to anything, because it would be already
The main issue here is that you're sort of asking for something too late.
If you reference the "notThis" keyword inside a callback method that has
been separated from "its own" class instance, you're now saying "could you
please do this all in the context of your instance", but your method
*@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
proposal and as far as I understand, it is just another way to create a
bound enclosing function. What I am proposing is just the opposite, no
binding should take place in the enclosing function. A method call or usage
of a
I would imagine that this can be achieved with bind operator proposal, which
already has Babel support, despite no examples showing usage inside a class.
Something like:
`oReq.addEventListener("load", ::this.responseHandler);`
seems to be the syntax that will de-sugar to
First of all, thank you all for taking the time to review the proposal and
sharing your valuable opinions. I would like to note that the proposal aims
not to add a new capability that was not possible to do before but rather
move the standard forward on the way for a modern, better and easier to
This is probably not the pattern that is being proposed though outputs the
expected result
```class RequestManager {
constructor() {
this.successMessage = "Xhr successful.";
RequestManager.THIS = this;
}
makeRequest() {
var oReq = new
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
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
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
27 matches
Mail list logo
