Function name proposal writeup
Thanks for this :-)
"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.
David
[1] johnjbarton.github.com/nonymous/index.html
Le 04/04/2013 01:35, Brandon Benvie a écrit :
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.
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.
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.
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.
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.
On 4/4/2013 12:47 PM, Allen Wirfs-Brock wrote:
What about function that are defined like:
Date.myParse = function () {...}.
This brings up another point I wanted to address but didn't think to at the time. It makes sense, since function names are being formalized, to also specify how builtin functions are named. Generally it seems pretty obvious: use the given name in the spec (following the rules, for example, for accessors etc.). But it should probably be stated explicitly.
...If you have concrete ideas on how to actually write the specification using concepts from the ES6 spec. methodologies, feel free to share...
I was thinking about this while writing the proposal up for the wiki. I'll put some time into coming up with ideas on how to do this.
I've added a wiki page with the function name proposal that was agreed upon [1]. It expands in more detail the original proposal and provides examples for most ways a function can be named.
One issue is statics were introduced after the proposal was written. Right now I simply have them take the name and not "static " but I could also see "static func" to match how accessors are named.
[1] harmony:function_name_property