13423 - xpidl could use a system for declaring nsresults

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P4)

Description

[John Bandhauer]

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 :)

Comment 1

[Brendan Eich [:brendan]]

This one also should go to mccabe.

/be

Comment 2

[Mike McCabe]

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

Comment 3

[Mike]

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

Comment 4

[Mike McCabe]

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

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 6

[Brendan Eich [:brendan]]

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

/be

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 8

[Mike McCabe]

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

Comment 9

[Mike McCabe]

Many good comments from Warren off in 44050.

Comment 10

[Phil Schwartau]

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 - 

Comment 11

[John Bandhauer]

mass reassign of xpidl bugs to [e-mail]

Comment 12

[basic]

any eta on this?

Comment 13

[David Bradley]

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.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 15

[Benjamin Smedberg]

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.

Comment 16

[Ben Bucksch (:BenB)]

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.

Comment 17

[Ben Bucksch (:BenB)]

(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.

Comment 18

[Benjamin Smedberg]

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.

Comment 19

[Brendan Eich [:brendan]]

(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

Comment 20

[Alex Vincent [:WeirdAl]]

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

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f9d2e85a6243
[fenix] For https://github.com/mozilla-mobile/fenix/issues/13423: Pass isPrivate flag to ToolbarView