Function name proposal writeup

Brandon Benvie bbenvie at
Thu Apr 4 12:02:04 PDT 2013

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]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list