Re: GIO API review

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-12-12 at 17:33 +0100, Michael Natterer wrote:
> Alexander Larsson wrote:
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
> >> G*Monitor:
> >> ==========
> >>
> >> GFileMonitor      -> GIOMonitorFile
> >> GDirectoryMonitor -> GIOMonitorDirectory
> >>
> >> Wouldn't it make sense to have a common (perhaps abstract) base class here,
> >> or derive one from the other? The APIs are very similar at least.
> > 
> > They are very similar, but I'm not sure what advantage a common base
> > class would have. Its not likely that you pass around an object that is
> > either a file monitor or a directory monitor, so GMonitor would not be
> > used anywhere.
> 
> Well the common base class would install the "changed" signal, it
> would have cancel(), is_cancelles(), set_rate_limit() and emit_event()
> APIs, they would share their properties, and they would share the code
> instead of duplicating it.

The actual amount of code duplicated is really small (_emit_event is the
only non-boilerplate code and it can't be shared), especially
considering all the extra boilerplate required to define a baseclass
with gobject. 

> GIOMonitor would simply be an abstract base class, and it doesn't
> matter if you really need the polymorphy here (passing them around
> around as Monitor instead of File or Directory monitor), the point
> is that there is code duplication in two very similar classes,
> that almost cries for a common base class.

It just adds new types and type relations you have to learn, and forces
you to remember that you have to cast to some common class to do things
like cancelling a directory monitor. It adds nothing useful to the user
of the API, it just means you have to learn more and remember more.