Open Bug 420147 Opened 16 years ago Updated 2 years ago

Fix the mess of Cc/Ci/Cu/Cr being (re)declared all across code

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect

Tracking

()

People

(Reporter: kairo, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

The Cc/Ci/Cu/Cr shorthands are currently (re)declared all across files in JS, http://mxr.mozilla.org/seamonkey/search?string=C%5Bciru%5D+%3D+Components&regexp=on&find=&findi=&filter=&tree=seamonkey currently find 435 declarations in the tree.

We should clean up this mess and either kill the shorthands and use the long form everywhere or define the shorthands globally for all JS code that can use XPConnect.
I don't think that killing the shorthands is a good idea...
Unfortunately, as http://mxr.mozilla.org/seamonkey/search?string=+C%5Bciru%5D+%3D&regexp=on&find=&findi=&filter=&tree=seamonkey turns out, we even have other meaning for those var names, at least for names only differing in case.
And if we declare them globally, the question remains if it's a good idea to define global variables without a "g" prefix or constants with mixed case.
This would really make mozilla-based apps' lives easier.

From what I hear, either you tend to re-declare Ci/Cc in a lot of scripts, or you die in the one off risk that a global declaration isn't imported in some script. Bottom line: it's bug-prone.

CC'ing some XPConnect people (sorry) -- what do you guys think, is it a reasonable request/change to make the runtime provide us with this?
I do not think we should pollute the global namespace, even for code that we somehow know is "chrome". I also think we should continue to use the shorthand. Is there a way to define a "const let" or something similar so that we don't pollute the global object but only use the declaration for the particular script we're in?
scripts don't define a scope, though with program units (dropped from ES4) we might have been able to do something similar.  We could delete Cc/Ci/Cr/Cu at the end of the script, to similar if less automatic effect.

I don't think that polluting with Cc/Cr/Cu/Ci is a big deal, personally, though I think it points to an architectural problem that we can't just define them in one place and then be sure that such code is available to everything.  We want to be implementing more utility code in script, which requires some similar pattern.

Probably the most fun aspect of this is the way that the Mac hidden window carries definitions to places they aren't in scope on other platforms. I guess religious use of the tryserver would cut down on the number of landings that burn everything but Mac, though.
Yeah, the bottom of the hidden window code is probably the first place that I'd stick the deletions of C[ircu] to see if it helped.  It would actually be doing the inverse of this bug, I guess, but would avoid the platform disparity, which I think is the biggest practical problem.
const C[iruc] vs let/var C[iruc] also causes problems with code trying to detect the presence of the shorthand and declaring them if not present.
Blocks: 484062
(In reply to comment #8)
> const C[iruc] vs let/var C[iruc] also causes problems with code trying to
> detect the presence of the shorthand and declaring them if not present.

Yes, I really think we should find some way to just have them always declared in global scope - or use something different than those current shorthands.
Does exporting them from a JavaScript module work?
Could we just make them exist in all chrome JS contexts, but be settable, so it wouldn't break any existing code? Then we could just remove all the places we set it and code could rely on it existing.

Alternately we could find a less-verbose way to write XPCOM JS ;-)
(In reply to comment #10)
> Does exporting them from a JavaScript module work?

I just tried this, creating a Components.js module and importing it into browser.xul's global object.  Importing Components.js worked--the four symbols (Cc, Ci, Cr, Cu) were imported without incident, despite already being defined in browser.xul--but afterwards, calling Cu.import in browser.xul imported modules into Components.js's global object instead of browser.xul's global object.
(In reply to comment #11)
> Alternately we could find a less-verbose way to write XPCOM JS ;-)

Srsly -- isn't it time (I thought FUEL would do this) to have sweet Ajaxy JS code hiding all this C[ciru] grot?

/be
Yes. I've been requiring most of the new APIs to be declared in terms of JS and imported modules, with XPCOM only under the covers... but there's a lot of existing mess and it won't go away in a day or a year.
(In reply to comment #12)
> (In reply to comment #10)
> > Does exporting them from a JavaScript module work?
> I just tried this, creating a Components.js module and importing it into
> browser.xul's global object.  Importing Components.js worked--the four symbols
> (Cc, Ci, Cr, Cu) were imported without incident, despite already being defined
> in browser.xul--but afterwards, calling Cu.import in browser.xul imported
> modules into Components.js's global object instead of browser.xul's global
> object.
Well, that still gives us a few options:
1. Just export Cc, Ci and Cr
2. Export Cu but don't use it for Cu.import
3. Explicitly pass window to Cu.import
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.