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

List:       gtk-devel
Subject:    Re: GIO API review
From:       Martyn Russell <martyn () imendio ! com>
Date:       2007-12-13 15:17:50
Message-ID: 47614D1E.5030703 () imendio ! com
[Download RAW message or body]

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 :)

-- 
Regards,
Martyn
_______________________________________________
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]