Re: GIO API review

[Michael Natterer <mitch imendio com>]

Alexander Larsson wrote:
> 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.

But we have casts all over the place in gobject/gtk+. And the APIs of
both classes is 100% *identical*. You can't seriously argue against a
common interface. In this case, having a common base class strikes
me almost as a no-brainer.

How would you justify having the *exactly* same API twice on two very
closely related classes? I would rather argue that having to learn
only *one* GMonoitor API is much more obvious and straightforward.

The actual implementation details (the fact that there are subclasses
at all) could be almost invisible in the public API.

- two closely related classes
- two identical APIs
-> common base class

*please* :-)

ciao,
--mitch