On Tuesday, December 11, 2012 3:08:28 PM UTC-8, Jeff Walden wrote: > 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? > > 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.
Agreed. > > -- 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. My first choice would probably be Array_indexOf, even though it's not terribly pleasing to the eye, on the grounds that it's the minimal change from the original Array.prototype.indexOf. > > -- 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. Agreed. > > b) Should the names of macros indicate how they're implemented or should > > they just look like other functions? It seems like a good idea to make them easily identifiable as having parse-time effect rather than run-time effect. I expect library module implementers are more interested in knowing precisely what their code is doing than in being able to ignore what kind of construct they are using. > > -- Should the macro checking for undefined be named IS_UNDEFINED or > > isUndefined? Or even $isUndefined, 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. That works too. > > -- 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). Like David Bruant said, we can use modules once we have them, like an 'ecma' module for ToInteger and ToUint32. In the meantime, I think we can leave them unprefixed. Dave _______________________________________________ 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
