On Dec 17, 2012, at 16:15 , Dave Mandelin wrote: > 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.
So, follow the conventions of function naming used in the ECMAScript specs? >>> -- 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. I started with a different opinion, but since the next item means we're going to have capitalized non-constructors anyway, I agree with Dave: Array_indexOf is not pretty, but it's an obvious derivation from the ECMAScript name. >>> -- 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. OK, I can live with that. >>> 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. I'd rather be able to change the implementation of a function without having to change all its callers. Having the names be different for macros and functions would make sense if you imagine having both kinds for the same functionality at the same time and letting callers choose which one to use - do you imagine that happening? >>> -- Should the macro checking for undefined be named IS_UNDEFINED or >>> isUndefined? > > Or even $isUndefined, or %isUndefined? My choice would be 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. When happens when the value of the |undefined| variable of one frame is passed to another frame? Does it compare === to the |undefined| variable of the other frame? >>> -- 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. That is, treat it like a function. :-) >>> 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. OK. I'm not quite so optimistic about modules coming to self-hosted code soon - it's been a tremendous amount of work for Till to bring up more and more functionality in this environment that normal JavaScript code can take for granted. But then, we don't have all that much self-hosted code yet either. Norbert _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
