[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: GIO API review
From: Alexander Larsson <alexl () redhat ! com>
Date: 2007-12-13 15:10:34
Message-ID: 1197558634.6577.106.camel () dhcp-208-188 ! arn ! redhat ! com
[Download RAW message or body]
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?
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic