Le 11/12/2012 04:02, Norbert Lindenberg a écrit :
Till, Jeff, and I had some discussion about naming conventions for self-hosted
JavaScript - would be good to get input from others. I tossed in a few more
cases that I've come across.
a) Should we follow established JavaScript conventions and allow only constructor and
namespace names to start with a capital letter (i.e., Array and Intl)? Or should we
follow the SpiderMonkey C/C++ conventions, which allow other functions to be capitalized?
Note that the latter requires turning off checking for proper usage of "new" in
JSHint (yes, I do think we should use code checkers).
Concrete cases:
-- Should the function implementing Array.prototype.indexOf be named
ArrayIndexOf, arrayIndexOf, or array_indexOf?
No opinion
-- Should the function implementing the ECMAScript abstract operation ToInteger
be named ToInteger, toInteger, or __ToInteger?
Since these are direct algorithms, it might be worth either using the
exact same name (and case) or prefix to explain that it's supposed to be
the exact implementation of a spec algorithm, like: "spec_ToInteger" or
"Spec_ToInteger", "ES_ToInteger".
For people knowing well the spec, a prefix may not be necessary to
understand the code and that it's a spec algorithm. For people less
familiar with the spec, it may be an indication that they should check
the spec before touching the function. A comment may do the job as well.
b) Should the names of macros indicate how they're implemented or should they
just look like other functions?
Is there a value in indicating how they're implemented? Like, does
knowing how it's implemented can help make a choice that will influence
maintainability? performance?
If not
-- Should the macro checking for undefined be named IS_UNDEFINED or isUndefined?
Depends on answers to above questions
-- Should the macro implementing the ECMAScript abstract operation ToUint32 be
named TO_UINT32 or (depending on the decision for ToInteger above) ToUint32,
toUint32, or __ToUint32?
I think again that spec algorithms should have their own convention
regardless of how they're implemented.
c) Should we prefix the names of global functions and variables to create name
spaces?
I think modules are "around the corner" (probably a couple of months
away, but that's not much compared to how long they'll live), so I use
the following question as a corollary: "what is the thing that will
require less work when modules arrive?"
If these functions (ToUint32, isUndefined, etc.) were to be put in a
module, they would be put with their direct name ("the module is the
namespace" if you will). When imported, it would be unlikely that they'd
be aliased to something different (in the context of self-hosting at least).
So I wouldn't prefix.
David
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
