John Bandhauer wrote:
> David Brittain wrote:
>
>> In C++, it not a problem. Neither is it in Java where using the #pragma
>> directive in IDL you can get the generated Java file to be placed in a
>> package. However, in javascript in seems that there is a problem.
>>
>> In the scripting interface for our product we have the following sort of
>> structure:
>>
>> interface IBrowser
>> {
>> INode getNode();
>> }
>>
>> interface INode
>> {
>> function1();
>> }
>>
>> interface IImage : INode
>> {
>> function2();
>> }
>>
>> Now if the IBrowser interface returns an INode which actually is on an
>> object that supports the IImage interface, then the only way to call
>> function2() is by using QI to get the IImage interface.
>>
>> It's bad enough that we have to call QI (which we don't have to do
>> under IE or NS4.x) but if we also have to use IID's in javascript (can
>> you do this?)
>
>
> No. Only named interfaces are allowed.
>
> I am working on an extention to xpconnect that does what we call
> 'flattening'. The idea is that xpconnect will automatically
> flatten the view of the interfaces of an object. So, JS code for
> your example above would see an object containing all of the
> methods of each of the interfaces on the object.
>
> This will require the native object implementor to give us access
> to a 'ClassObject' from which the set of interfaces can be
> discovered by xpconnect in order to make use of the feature.
> There are issues with potential shadowing of like-named methods
> and a scheme for disambiguation. We need this all in order to
> convert the DOM system away from its big bundle of generated C++
> code and toward using xpconnect. I am working on this. It will
> not be ready to deploy for some time.
>
> John.
The flattening sounds like what I need, is there a enhancement request
in Bugzilla for tracking the progress of this work. Is this likely to be
included in Mozilla 1.0?
Dave
