Re: GInterfaces and API Stability

[Mike Kestner <mkestner novell com>]

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?

> 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.

-- 
Mike Kestner <mkestner novell com>