Use cases for own methods

[littledan]

I like the aesthetics of having own methods to "complete the grid" and make an orthogonal system, but I'm wondering about the usage of this feature. I've heard from @sebmarkbage (please correct me if I'm misunderstanding) that own methods are useful for a couple things:

• Bound methods (which this proposal doesn't provide, but could use the public fields syntax method = () => {})
• Own getter-setters, so they show up in Object.keys, Object.assign, object spread, etc (which is provided here)

Any other usage scenarios? Collecting these might help us feel more comfortable about the ergonomics. As it is, I'm a little worried about how useful the feature will be besides providing some measure of orthogonality (in a grid which already has other holes).

I'm also worried that much of the usage might be people writing own before methods for not much reason, just because they have to write it in many other places in classes, and it has very similar behavior from a casual observation.

[allenwb]

I'm also worried that much of the usage might be people writing own before methods for not much reason, just because they have to write it in many other places in classes, and it has very similar behavior from a casual observation.

It seems just the opposite to me. Prototype placement methods are,. by far, the most common kind of class element and the concept that (prototype) methods don't have a keyword prefix is already well established by ES2015. Anybody prefixing own in front of all of their methods for no reason clearly would have a misunderstanding of who classes work. The whole point of this proposal is to provide an easily learned, orthogonal syntax that minimizes that confusion. Basically, non-prefix means shared by all instances and own means distinct for each instance. Hard to see how to make in any simpler.

[littledan]

Well, I can understand it well, but imagine someone who comes from the current Babel syntax, and sees, "OK, TC39 wants me to put own in front of a some class elements make my code work in real ES2019? Fine, I'll put own in front of a bunch of things."

This could also be someone who is coming from another programming language which doesn't give you the option of putting things in all these various places (I can't think of any other language that has a convenient syntax for both own and prototype/class methods like this); the distinction/motivation may feel subtle for them and so they might not get this analogy, thinking the object system will just figure it out which things are on the class and which are on the instance (as in other languages where all methods are on the class, and all non-static member declarations on the instance). I'm not saying we should design the language exclusively to suit this sort of analysis, but I think it will come up.

The fact that you put own in front of all private methods in this proposal (even if you don't have a particular need for them to be different on different instances, just for reasons about consistency of the object model that many programmers might not be thinking about all the time) could make this even muddier. A user might want to use the same syntax for declaring their public and private methods, except for the #, and they have that with this proposal: always use #. Their code will typically do the same thing, except it might be harder to optimize the public methods.

Anyway, I'm thinking about this as a cost-benefit analysis. If this is something users will find solves their problems, it could pay for its cost of potential user confusion. So I opened this thread to collect more use cases.

[allenwb]

@littledan

The fact that you put own in front of all private methods in this proposal (even if you don't have a particular need for them to be different on different instances, just for reasons about consistency of the object model...

No, that isn't the reason only own private methods are shown in the examples. As explained private field hosted methods on prototypes don't work because there is no direct way to reference them. For that reason, they are explicitly left out of the orthogonal matrix. On the other-hand, private field hosted own methods work just fine, although they probably have fairly limited utility. But since they work, it makes sense to include them in the orthogonal feature matrix.

As discussed in #2 class lexically scoped function declarations are probably a better solution for use cases where prototype placement "private methods" might be considered.

[allenwb]

Any other usage scenarios?

Well, I tried to suggest one via this example from the proposal:

class {
   own #callback(){}  //a private instance method  
   ...
   setCallback(f){this.#callback=f}
}

This is essentially a function valued per instance private field that is initialized to some default function value. However, on a per instance basis the function value of the field can be set to some other function value.

Using public properties, the default could be provided via a prototype method which is over-ridden only on those instances that set the property to something other than the default. But that won't work using private fields because instances don't inherit access to prototype private fields.

[littledan]

As explained private field hosted methods on prototypes don't work because there is no direct way to reference them.

Yes, I agree that, unless you do something different, not based on an actual prototype, such as lexically scoped functions or an ad-hoc semantic as described in https://github.com/tc39/proposal-private-fields/blob/master/METHODS.md , private methods must be own. I guess one related question is, what do users' intuitions tend to be? This affects which would feel more exceptional/inconsistent.