Function name proposal writeup

Brandon Benvie bbenvie at mozilla.com
Thu Apr 4 12:57:00 PDT 2013


On 4/4/2013 12:47 PM, Allen Wirfs-Brock wrote:
>> I would argue that the best name for the method is "add" while the 
>> path/origin of it might be "Set#add". They are orthogonal in my 
>> opinion, and "name" is much simpler to specify.
>
> This would seem to argue against prepending "static".  Also it 
> wouldn't make much sense to do that if we also didn't consider, for 
> example Date.parse, to be "static".
>
> What about function that are defined like:
>
> Date.myParse = function () {...}.
>
> This may not be particularly any harder to formally specify than other 
> LHS forms (and the other are not necessarily all that easy).  If you 
> have concrete ideas on how to actually write the specification using 
> concepts from the ES6 spec. methodologies, feel free to share...

This is why I avoided adding "static " to the name. It makes sense with 
accessors to add "[gs]et " to the name but much less so for static. I 
suppose that partially depends on the way that people end up using 
statics though. In current usage, "static" functions attached to 
constructors are generally done so for namespacing only. It's possible 
we may see a rise in the use of |this| sensitive static functions such 
as `Array.of` and `Array.from`, and for these the "staticness" of the 
function actually matters. But since we rarely see that in current usage 
I don't think we can make an assumption that it will change much in the 
future.

> Finally, a minor point is that you failed to mention GeneratorFunction 
> declarations and expressions, but the intent for those is pretty obvious.
Yeah, I forgot that they are separate; I'll add them to the wiki page. 
But yeah, obviously they follow the behavior of 
FunctionExpression/Declaration.


More information about the es-discuss mailing list