On Dec 18, 2012, at 18:35 , Dave Mandelin wrote: > 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: >>>> 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.
We can't make it a keyword - the language spec allows functions to have their own |undefined| variables, and we have to assume that's done somewhere on the web. ES5 moved closer to making it work "like a keyword" by making the |undefined| property of the global object read-only, so as long as a script doesn't create its own |undefined| variables, it can rely on |undefined| being undefined within a frame. Cross-frame behavior isn't defined in the language spec, but different globals are involved. >>>>> 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. It depends on how fast we add self-hosted code. The more we add, the more likely we'll see clashes. At this point, there's no problem yet. I guess we can go unprefixed for now and see whether clashes or modules appear sooner. Norbert _______________________________________________ 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
