On Tuesday, December 18, 2012 6:08:53 PM UTC-8, Norbert Lindenberg wrote: > On Dec 17, 2012, at 16:15 , Dave Mandelin wrote: > > On Tuesday, December 11, 2012 3:08:28 PM UTC-8, Jeff Walden wrote:
> So, follow the conventions of function naming used in the ECMAScript specs? That's what makes sense to me. > >>> -- 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. > > >>> 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? No, and the notion of being able to change from a macro to a function without changing the callers is a good argument. > >>> -- Should the macro checking for undefined be named IS_UNDEFINED or > >>> isUndefined? > > > Or even $isUndefined, or %isUndefined? > > My choice would be isUndefined. Sounds good. > >> 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? I think Jeff was suggesting |undefined| would become a keyword instead of a variable. In the current state of things, |isUndefined| does seem better. > >>> -- 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. :-) :-) I glossed over the fact that it was a macro. But yes, that sounds fine. > >>> 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. You are probably right that it's not coming that soon. So, do you think prefixing is necessary? If there's a good reason to do it, then we should. 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
