On 13/12/2007, Martyn Russell <martyn@imendio.com> wrote:
> Alexander Larsson wrote:
> > On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote:
> >> Alexander Larsson wrote:
> >>> 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* :-)
> >
> > I don't think is so important, so sure, lets do this.
> >
> > However, what would the name of the base class be? GMonitor? That
> > strikes me as a bit to generic. GFileSystemMonitor? GChangeMonitor?
>
> GFileSystemMonitor gets my vote.
> Unless you want to go for GIOMonitor :)


There is also a third monitor that has not been mentioned in this
context - the volume monitor. Looking at the code I see that it is not
exactly in the same spirit as the file and dir monitors, but it might
be confusing that it does not have GMonitor as base class when other
monitors do...

Just a thought. Cheers,
Mikkel
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list