Static method syntax is unatural

[evilpie]

This was already discussed on irc and in that issue. This ticket is here until someone finds a better alternative or we accept the current way.

I dont like the @ syntax, because in class context it refers to 'this', wich can only exits in an instance, and the @ for staticmethod has explicitly nothing to do with the instance.

Here are a few ideas, although i think these arent perfect solution.

1. Prefix every instance method with @ and dont prefix staticmethods
2. Prefix every instance method with :: and dont prefix staticmethods (the :: already stands for prototype to this would be someway consistent)
3. Lets try to find some other not yet used cool character, like ♥ ;)

[weepy]

I agree with this. Really the :: makes most sense.

[michaelficarra]

Ruby uses @@ for class variables, which works pretty well for them and goes very nicely with the current @ notation for instance variables.

[TrevorBurnham]

Yes, @@ for class variables would be nice. And @@ by itself should refer to the current class, just as @ can be used as shorthand for this. +1

[evilpie]

@michaelficarra
Good idea.
Note: Something i just looked up c++ uses :: for static!

@TrevorBurnham
I am afraid of seeing code like this:
class Test:
constructor: ->
@@::lol: -> "wtf"

[TrevorBurnham]

@evilpie Sure, it could be misused, but I don't like having to use the class name every time I want to reference a class property within the class. It's syntactic sugar, and it means I'm less likely to have to do a find-and-replace every time I decide to rename a class. I think that making refactoring easy should be a high priority for a language.

[weepy]

surely @@ can be expanded to this.constructor ?

[evilpie]

I think it would implementing it in function easier, but it would again be different in how it behaves for classmethods. @@ should yield the name of the current class, function, object

[jashkenas]

Sorry, folks -- this one is a wontfix. We don't really need another piece of symbology just to reference this.constructor -- a fairly rare occurrence in any case. If you find yourself stashing a bunch of to-be-referred-to properties directly on the class, using @property:, you probably want to be putting them as regular prototype property: ... where they can be shared and inherited directly on this...

Languages like Ruby that can't have data on the same level as instance methods need storage on the class object for tagging classes with extra metadata, but in JS putting it on the prototype is a perfectly fine location.

[aminland]

Is this still something that is out of the question?

Classes weren't that common in use before, but nowadays i find they are everywhere, and I am almost never having to access the prototype, but rather the static methods on the class from within a class instance. This pattern is really encouraged with react...

Thoughts?

[GeoffreyBooth]

I’m not sure we need another syntax for static methods. What would it be?

Keep in mind there are class decorators (#4917) working their way through the ES approval process, and we’ll probably need @@ for those.

[aminland]

My suggestion was to keep static method declaration as is, and use @@ for this.constructor shortcut, and an alternative syntax for class decorators, given that @ has special meaning for coffeescript. There are plenty of alternative decorator syntaxes in the decorator discussion thread.

…

On Fri, May 11, 2018, 2:03 AM Geoffrey Booth ***@***.***> wrote: I’m not sure we need another syntax for static methods. What would it be? Keep in mind there are class decorators (#4917 <#4917>) working their way through the ES approval process, and we’ll probably need @@ for those. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#533 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOFkOuita-9HBBdDLDr7mPEiHr2bObXks5txSmogaJpZM4T6iPf> .