Neil Stansbury wrote:
Why not? As long as there are no local variable collisions (and their
usually won't be) the the code is auto-documenting, anyone reading then
immediately knows what interface the variable represents. Same when
QI'ing the interface.
I disagree that it's auto-documenting, it sounds like the variable is
actually representing the interface, not an instance of it.
And in Mozilla code, that's actually often the case, e.g. in cases like
this:
const nsIChannel = Components.interfaces.nsIChannel;
That's a pretty common pattern.
Actually, in JS we have now started using the Components.Constructor
which enforces a slightly different mechanism with "ns" rather than "nsI":
I don't really see how that enforces it...
var nsIProtocolHandler = new
Components.Constructor("@mozilla.org/network/io-service;1",
"nsIIOService", "getProtocolHandler");
var nsFileProtocolHandler = new nsIProtocolHandler("file");
Are you sure that this is doing what you think it does? My reading of
http://www.mozilla.org/scriptable/components_object.html#_Constructor
sounds like you are actually creating multiple instances of the IO
services that way, which is a really bad thing. It would also lead me to
believe that this stores the IO service in nsFileProtocolHandler, not
the handler.
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom
