Yes, this is what I do to overcome the scoped meaning of this:
class MyClass {
methodOne() { return 1; }
methodTwo() { return this.methodOne() + 1; }
methodThree() {
const me = MyClass.prototype; // avoid the use of this
return me.methodOne() + 1;
}
}
const myInstance = new MyClass();
const myOptions = {
failingMethod: myInstance.methodTwo,
successfulMethod: myInstance.methodThree,
};
console.log('success', myOptions.successfulMethod()); // returns 2, as expected from accessing other class memebers.
console.log('fail', myOptions.failingMethod()); // throws an Error, as the original meaning of 'this' is changed.
So basically, what I was asking falls back into having a me property as a shorcut for Class.prototype, different from this, but also available in the syntax.
For that scenario, I think a more common approach would be to store those functions as static methods. methodOne() doesn't actually need access to this, so it doesn't actually need to be a method on the object, it can simply be a method on the class.
class MyClass {
static methodOne() { return 1; }
static methodThree() {
return MyClass.methodOne() + 1;
}
}
const myOptions = {
successfulMethod: MyClass.methodThree,
};
console.log('success', myOptions.successfulMethod()); // returns 2, as expected from accessing static members
The specific functionality of the example is irrelevant. It simply shows how the meaning of this can change in a different scope, hence the claim of a keyword that keeps access to the class members regardless of the scope.
Say the class was defined in a different script, some time ago.
Now you want to import some of its functionality in a different implementation (not considered when the class was defined). In that case, a consistent keyword to shortcut the access to the prototype would retain the meaning in a different scope.
I believe the counter of using "static methods" applies generally.
If "this" refers correctly to the instance of the class, then you can just do this.methodName() to call another method. It sounds like you're trying to handle the case where "this" does not refer to an instance, because the method which was called was plucked off the instance previously, and got called out of context. To account for this, it sounds like you're suggesting that people use a "me" keyword that points to the class's prototype. The problem is that this solution only works if "me.methodName()" doesn't need access to any data found on the instance (because such data isn't available - "this" is pointing to the wrong thing, and "me" only points to a prototype). But, if "me.methodName()" doesn't need access to any instance data, why is it found on the instance to begin with, instead of being found as a static method on the class?
So, if I understand your second proposed scenario, I believe the solution is the same. If you have an old class, and you want to, at runtime, pluck methods off of it and put it into a new class, 1. that sounds messy and unmaintainable, I would suggest refactoring to extract shared helper logic outside of the class (maybe get it under test first if you're worried about breaking changes), but even if you don't do this, 2. if the old class really had methods that didn't access any member data, those should have been static methods, and then you could easily pluck those off and use them. If its methods do access instance data, then using "me" wouldn't be able to solve the issue either, since "me" would point to a prototype, not to an instance with data to operate on. But, maybe I don't understand this example correctly?