Re: Additions to GInterfaces

[Owen Taylor <otaylor redhat com>]

On Thu, 2005-12-01 at 18:04 +0100, Murray Cumming wrote:
> On Thu, 2005-12-01 at 14:07 -0200, Johan Dahlin wrote:
> > Mike Kestner wrote:
> > > When auditing the new API in 2.8 for Gtk#, I noticed that a property and
> > > signal were added to the FileChooser interface.  Adding anything to an
> > > interface is a non-compatible change, because any class implementing the
> > > interface must be updated to add the new API members.
> [snip]
> 
> Ah, I missed that. I guess that the interface should check for a null
> function-pointer and have some default functionality for that case.

C++ has a fairly weak requirement here - if an *empty* implementation of
the added function keeps everything working, then you can extend
interfaces and keep compatibility. If an empty implementation is
different from a NULL pointer, then this gives problems. (Like the
problems that gtkmm has with the spinbutton input/output signals.)

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.

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.

Regards,
						Owen