Function name proposal writeup

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Apr 4 12:47:14 PDT 2013


On Apr 4, 2013, at 12:02 PM, Brandon Benvie wrote:

> On 4/4/2013 11:52 AM, David Bruant wrote:
>> "The name property is initialized with the best value given static semantics"
>> => I think all the rules should be explicitly laid out (i think that's what you did in the subsections after this sentence) to avoid implementation-specific interpretations of this sentence. Some previous work [1] could be considered as finding "the best value given static semantics".
>> Also, "given static semantics" is a fluctuating definition since the result can change when new syntax is added.
> 
> Yeah, the purpose of that paragraph is to intro the following content, not stand alone. I agree that it could be improved and clarified; a better phrasing might be "given the following static semantics...". The set of rules used to name functions should not (and I don't think it does) leave any room open to interpretation by implementers.
> 
>> [1] http://johnjbarton.github.com/nonymous/index.htm
> 
> This is good stuff but I would argue that it's not naming the function. It's providing a path or description of its origin, suited for debugging rather than naming. For example:
> 
>     class Set {
>       add(item){ /***/ }
>     }
> 
> 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...

Finally, a minor point is that you failed to mention GeneratorFunction declarations and expressions, but the intent for those is pretty obvious.



Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130404/97beb9f0/attachment.html>


More information about the es-discuss mailing list