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 <[EMAIL PROTECTED]> _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list