from... news://news.mozilla.org/37C353F4.B9928132%40netscape.com I would love to see us declare our nsresult codes in xpidl. If we do this then the codes will be automatically reflected (at interface scope) into all of our language mappings. The system for constants in xpidl will do almost all the work. What I think that we need to add is a little xpidl magic to pull this off. // global predefined xpcom error codes and module base codes interface nsResult : nsISupports { const nsresult OK = 0; // ... const module_base FooModule = GenModuleBase(1); const module_base OtherModule = GenModuleBase(2); // ... // Many interfaces can just multiplex off the generic base // rather than require their vvery own module number const module_base GenericInterfaceModule = GenModuleBase(10); // ... }; // my interface in my module interface nsIFoo : nsISupports { const nsresult MY_ERROR = GenError(1, nsIResult::FooModule); const nsresult COPIED_ERROR = nsIResult::OK; }; In C++ one would use: nsIResult::OK or nsIFoo::MY_ERROR where now we say NS_OK and NS_ERROR_FOO_MY_ERROR. In JS you could use : Components.interfaces.nsIResult.OK ...or perhaps... Components.results.nsIResult.OK In order to implement this we need: 1) support for typedef'd types in const declarations (we should do this anyway). 2) xpidl support for better parsing of the rhs of const declarations to deal with these 'function call like' and 'static data member like' constructs. 3) simple backend code to do the calculations for GenModuleBase and GenError. 4) tracking of those results from included files. Then, of course, we would have to spam the tree and fix our heads to follow the new syntax. The names might change, but this is the idea. I'm not really signing up to do all this right now. Brendan is hip deep in the compiler front end and might want to do that part? McCabe is hip deep in the compiler back end and... well you get the rest :)

This one also should go to mccabe. /be

Not needed for the short term; changing milestone. I read your Components.results documentation, and this does seem like something that'd be nice.

M16 has been out for a while now, these bugs target milestones need to be updated.

[SPAM] Marking milestone 'future' as part of nsbeta3 triage.

I had been under the impression that this was going to be done as part of the architecture review sweep. Brendan?

Cc'ing warren. I don't know of anyone with time to do this right now. /be

<http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsIErrorService.idl> contains the current workaround that's in use.

*** Bug 44050 has been marked as a duplicate of this bug. ***

Many good comments from Warren off in 44050.

Mass-reassigning mccabe's non-JS, non-Rhino bugs to jband (34 total). Would like to cc mccabe; but the mass-reassign page does not allow this. I'll leave it up to mccabe to decide if he wants to be cc'ed on these -

mass reassign of xpidl bugs to dbradley@netscape.com

any eta on this?

A quick note, for anyone interested in doing this, there should be NS_SUCCEEDED and NS_FAILED types of functions as well provided by this.

Benjamin: can you elaborate on why you WONTFIXed this bug?

Because I don't believe that the future of our apps is primarily in XPCOM and I don't think we should spend effort on it.

So, you're essentially wontfixing XPCOM? I don't think that's good reasoning. XPCOM components are were so far needed for all substantial XULrunner applications, and the error codes are a massive problem when developing them. That's not to start with the many dozens of Mozilla components, which often don't publish error codes to JS either, to my knowledge.

(In reply to comment #16) > XPCOM components are were so far needed for all substantial XULrunner > applications I mean custom XPCOM components here, e.g. for Songbird, TomTom HOME, Birgin IDA etc., pretty much all bigger XULRunner apps I know.

I do not think we should add more complexity to the XPCOM system. The future of binary interfaces is going to be jsctypes-style code, not binary XPCOM, and I want to focus XPCOM effort where it's going to make the most difference.

(In reply to comment #17) > (In reply to comment #16) > > XPCOM components are were so far needed for all substantial XULrunner > > applications > > I mean custom XPCOM components here, e.g. for Songbird, TomTom HOME, Birgin IDA > etc., pretty much all bigger XULRunner apps I know. Ok, but what does that have to do with this bug? Let's not polish a turd, or to be nicer, gild a lily. /be

Does anyone want to remove the little comment here? http://hg.mozilla.org/mozilla-central/annotate/fc6783c960ca/xpcom/base/nsIErrorService.idl#l45