Open Bug 665409 Opened 13 years ago Updated 2 years ago

XPIDL syntax does not allow for optional (null) values

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

People

(Reporter: dougt, Unassigned)

References

Details

The Web IDL draft allows for null parameters such:

attribute readonly double foopy;

If foopy can not be determined, it may return null (instead of throwing).  The syntax is '?', so you'd have something like:

attribute readlonly double? foopy;


See http://www.w3.org/TR/WebIDL/#idl-nullable-type for details.



This is a fall out from bug 615597 where we have many params that, if they can not be determined, we return null.
Fallout from bug 662678.
Also see the more up-to-date dev.w3.org version of the spec, which has expanded to allowing (requiring) "?" on types where null is allowed:

http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type
This probably needs to depend on us not using the C xpidl compiler, right?  Or can libidl handle this syntax?

In the meantime, you can express this as an nsIVariant, at some pain on the C++ end....

That said, what would the C++-end API for nullable double even look like?  The best I've come up with so far, short of using something like a variant is an inout |double*&| argument that the caller sets to a double on their stack and the callee either writes to or sets to null....
For parameters it would be double* aParam, and for return values
double** aRetVal.
(In reply to comment #3)
> This probably needs to depend on us not using the C xpidl compiler, right? 
> Or can libidl handle this syntax?

I don't believe libidl can handle this.
> and for return values double** aRetVal.

With heap-allocation when a double is actually returned?  :(
Why would it need to be heap allocated?

But sure, double*&  might be better.
> Why would it need to be heap allocated?

Well, the alternative is if it's an inout param, with the caller passing in a pointer to a valid double*.  But in that case I think double*& is clearer.
Yes, this depends on us switching completely to pyxpidl.
Depends on: 660861
Version: unspecified → Trunk
So, we've switched to pyxpidl now.  This doesn't seem like it should be particularly hard to implement in XPConnect once we decide what the C++ side should look like.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #10)
> So, we've switched to pyxpidl now.  This doesn't seem like it should be
> particularly hard to implement in XPConnect once we decide what the C++ side
> should look like.

I'm happy to do the XPConnect bits.
bholley, don't you want to lean the pyxpidl bits also?

I don't think we need to mess with extra levels of indirection, just add another argument, e.g.

nsresult GetFoopy(double* aResult, bool* aResultIsNull)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> bholley, don't you want to lean the pyxpidl bits also?

Not sure if that was intended to be a joke or not, but yeah, sure. ;-)

Taking. What's the general priority of this?
Assignee: nobody → bobbyholley+bmo
Depends on: 691781
Depends on: 692342
Depends on: 693454
Realistically, I don't think this is likely to get done early enough to make it worth doing before we switch over to the new DOM bindings. Once we have a better idea of what they'll look like, we can decide how best to support this.

Unassigning for now.
Assignee: bobbyholley+bmo → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.