On 12/10/2012 10:02 PM, Norbert Lindenberg wrote: > 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?
I wouldn't call these truly "established" conventions. Beyond that, if the spec methods have to be exceptions, I don't see that as truly bad. Foolish consistencies, and all that. If we can use something like // nohint for this, that would solve this immediate problem, to be sure. Note that I don't see special value in having similar styles for C++ and JS; they're just too different for me to see it as a goal in and of itself. > Note that the latter requires turning off checking for proper usage of "new" > in JSHint (yes, I do think we should use code checkers). I'm not a fan of jshint. But it's also possible I'm just not familiar enough with its full configurability, to know that it makes choices I agree with enough. > -- Should the function implementing Array.prototype.indexOf be named > ArrayIndexOf, arrayIndexOf, or array_indexOf? Dunno. We're moving away from C-heritage underscores as word separators in our other code, so I somewhat dislike the last. > -- Should the function implementing the ECMAScript abstract operation > ToInteger be named ToInteger, toInteger, or __ToInteger? ToInteger. If that's an exceptional case, so be it. > b) Should the names of macros indicate how they're implemented or should they > just look like other functions? > -- Should the macro checking for undefined be named IS_UNDEFINED or > isUndefined? We should make === undefined work so that this particular instance need not be considered. |undefined| should be used like a keyword IMO. Probably we'd need to do some work to make this happen. > -- 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? ToUint32. > c) Should we prefix the names of global functions and variables to create > name spaces? The implementation of the internationalization API has quite a > few of those, and to prevent clashes with code that other people may add in > the future I prefixed them with "intl_". (Many of these globals can also be > hidden inside a function closure once nested functions work in self-hosted > code). Ugh. I don't know at all here. Jeff _______________________________________________ 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
