Re: GInterfaces and API Stability

["Yevgen Muntyan" <muntyan tamu edu>]

On Wed, November 14, 2007 11:11 am, Mike Kestner wrote:
>
> On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote:
>
>> In the case you describe GetCells is a pretty core part of the
>> interface, and its clearly hard to not have it do much. However, that
>> doesn't mean there are times when its useful. For instance, the default
>> implementation of the method could call other methods on the interface,
>> allowing you to add an extended method with a fallback to the previous
>> unextended implementation.
>
> Which is probably no less ambiguous.  If I'm calling an extended method
> that I expect to take more information into account than the basic
> method, but all it does it discard my additional constraints or
> preferences and use an unextended method, then how do I know what I'm
> really getting as a consumer?

People argue for a thousand years already about what an "interface" should
mean. Different languages implement it in a different way (and some don't
implement it at all, yet are still "OO" allright). What does it have to
do with Gtk? Gtk interfaces can be extended, and the only requirement is
not to break existing code, namely it should cope well with existing
implementations of the interface which do not implement whatever new methods
are there.

So, Gtk breaks Gtk# because Gtk# developers assumed something wrong about
Gtk behavior, too bad. Perhaps it's a bad problem, such that it's better
to change Gtk to fix the problem, no idea, that's up to Gtk maintainers
(it does happen). But it's in no way something like "Gtk breaks holy
principles of OO => Gtk breaks compatibility". For me personally there is
no break here - just new API. But I don't do C# or Java, perhaps that's why.

>> Another example is an interface that is a bit more generic, like GFile
>> in libgio. You could add a new file operation that wasn't previously
>> supported in a compatible way by having the default operation return a
>> G_IO_ERROR_NOT_SUPPORTED. Code using this have to expect that errors can
>> happen anyway, as some backends might not be able to implement all
>> operations.
>
> I'm not sure I follow the example.  I agree it's possible write an
> interface method in a manner to make it clearer that failure is
> possible.  If you are saying that using this mechanism to provide
> optional interface methods is a good strategy, I would argue that
> providing a new interface to advertise the new capability is even
> better.  You can make it clear at compile time what capabilities the
> object supports.

And this should be argued on case by case basis, no? Like, is it better
to extend GtkCellLayoutIface or to add GtkCellLayoutHaveGetCellsIface?

Best regards,
Yevgen