I should probably mention here that like Ari Heitner I am also working on
Sash and the reason we want variants is so that we can have the same API
(or as similar as possible) to Sash for Windows, ultimately letting some
lowest-common-denominator Sash apps to run on both Linux and Windows with
no code change.
We might be able to fix the holes in the nsVariant patch (we have an XPIDL
hacker handy). Some input on what needs to be fixed will be very helpful.
As before, if anyone knows an alternative that would work right now,
please let me know.
> From what I gather the patch has some holes and is not complete. The
> current state is that it's been futured, and thus there is no time frame
> set for this. It probably won't happen before 1.0, unless more people
> demand the feature.
>
> As far as an alternative solution, I'm not well versed enough in JS to
> offer one. Maybe someone else here has done this.
>
> Sorry I'm not more help.
>
> Stefan Atev wrote:
>
>> I need to be able to write JS callable methods in C++ that have an
>> undefined return type at call-time, e.g.
>>
>> var regval= some_component.QueryValue() which would return either an
>> integer, a string or an array of strings.
>>
>> My understanding is that this is possible using variants, and that
>> variants are currently not supported by either XPCOM or XPConnect. My
>> problem is that the calls must be transparent to caller (callee side
>> complications are OK as long as no low-level hand-marshalling is
>> needed) so just wrapping everything around with objects is not a real
>> option.
>>
>> Is there any way (no matter how ugly) to achieve this without affecting
>> the JS side of things? Reading older threads and looking at bugzilla
>> bug 44675 gives me the impression that at some point this was possible
>> to do, but nsVariant is not currently included in XPConnect. What is
>> the status of this patch (read: is it usable in mozilla 0.9.1 and why)
>>
>> I'd be glad to work on any portion of XPConnect or XPIDL that would
>> lead to providing such functionality.
>>
>>
