[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GIO API review
From:       Michael Natterer <mitch () imendio ! com>
Date:       2007-12-13 13:43:18
Message-ID: 476136F6.8040309 () imendio ! com
[Download RAW message or body]

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

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]