Re: Additions to GInterfaces

[Mike Kestner <mkestner novell com>]

On Thu, 2005-12-01 at 12:34 -0500, Owen Taylor wrote:

> This requirement for C++ is weak because you can put a default
> implementation in the base class... it doesn't need to be pure
> virtual. But in Java and I think also C#, once the binding is updated 
> to match the extended interface, then app code will no longer compile
> unless it implements the missing member function.

Yes, this is the break I'm talking about in C#.

> The only real solution to that would be for the language binding
> to deviate from GTK+ and (hypothetically) add a FileChooser2 
> interface that extends the FileChooser interface. But that's ugly,
> so I'd agree with Mike that we really shouldn't extend interfaces
> that can be implemented by app code, even if we check for NULL.

I know FileChooser has some "creative" use of GInterfaces, but the
exposure of an interface method/prop/event that can't be implemented by
app code is problematic from a binding standpoint.  There is no way to
enforce this in C#, and I doubt it for java either. 

I'm hoping this is a one-time-only use of this
"public-consumption/internal-implementation" paradigm.
 
-- 
Mike Kestner <mkestner novell com>