125497 - Default arguments for XPIDL

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[aj]

Our current problem involves specifying optional arguments in an IDL that can 
be called from JavaScript and that correspond to underlying C++ functions. 
While we ourselves might require JavaScript coders to pass "null" in place of 
optional arguments, we don't have that liberty because we have to match several 
Windows APIs (see below), which with COM fully support optional arguments. For 
instance, one such function is
	boolean DeleteFolder(in string filename, [defaultvalue(false)] in 
boolean recursive_delete);

(or, also as in COM),
	boolean DeleteFile(in string filename, [optional] in nsIVariant 
recursive_delete);

In the former, if the second argument is not passed, DeleteFolder is invoked 
with the default value of false for that parameter. In the second, the optional 
parameter must be a variant, and the type is set to empty if it is not passed.

We feel that there are few if any downsides to such an addition because a) it 
does not invalidate any existing XPCOM code; b) optional parameters truly are 
useful: in our experience they are much more intuitive to JavaScript 
programmers than other solutions (passing null, or calling different 
functions), and they allow for some degree of method overloading; and c) 
increasing the compatibility with COM can only improve the credibility of XPCOM.

We are IBM developers implementing SashXB for Linux, an open source application 
environment that uses Mozilla and more specifically, XPConnect and 
SpiderMonkey. You can find more information about it here: 
http://oss.software.ibm.com/sashxb/

SashXB has a Windows analogue, Sash (http://sash.alphaworks.ibm.com/); we 
require API compatibility between the two products, which is why default 
arguments are so critical, since they are well supported in COM but not XPCOM.

Comment 1

[Asa Dotzler [:asa]]

setting status to New. 

Comment 2

[Benjamin Smedberg]

We now have [optional] and [optional_argc], and direct MS-COM compatibility isn't a concern, so I don't think there's any point in leaving this open.