Re: GIO API review

[Michael Natterer <mitch imendio com>]

Sorry for mis-following-up and resending, i have too many mail accounts.

On Wed, 2007-12-12 at 00:25 +0000, Emmanuele Bassi wrote:
> On Tue, 2007-12-11 at 21:22 +0200, Vincent Geddes wrote:
> > Hi,
> >
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> > > Also, subclasses should probably append their name, not prepend it:
> > >
> > > GFilterOutputStream -> GIOOutputStreamFilter
> > > GUnixOutputStream   -> GIOOutputStreamUnix
> > > ...
> > >
> > > This makes the file and inheritence structure much clearer and would
> > > be consistent with stuff we already have (e.g. GtkTreeModelFilter,
> > > GtkTreeModelSort).
> >
> > Looking over the GTK+ classes, it seems like the TreeView classes are
> > the odd ones out. Most classes seem to follow the naming pattern in 
gio,
> > examples being GtkToggleButton, GtkCheckMenuItem, GtkAccelLabel,
> > GtkAboutDialog, etc.
>
> true. :-)
>
> > Besides, the proposed naming in the review does go against the naming
> > convention set by Smalltalk, Java, C#, et al; and if implemented will
> > probably confuse users coming to GTK+ from those worlds.
>
> even though I usually favour internal consistency against the "proof by
> other language" when writing an API for my projects, in this case I
> completely agree: C++, Java, C# and other languages that have I/O stream
> classes went down the same naming policy with Type(Input|Output)Stream.

I agree it should be InputStream and OutputStream (instead of
StreamInput and
StreamOutput, which would be taking the proposal to its extreme), but
then
we have good examples for the "append" approach in glib (no need to take
GTK+ as an example here):

GParamSpecFloat
GParamSpecInt
GParamSpecFoo
...

This also enables comfortable working with the source code:

> ls gio/gioinputstream*.h
gioinputstreamfile.h
gioinputstreamfoo.h
gioinputstreambar.h
...

> grep foo gio/gioinputstream*.c
...you get the idea.

(yes i know you can ls and grep with the other approach too, my point
is rather that it's nice and helpful to recognize common ancestry by
common prefixes)

As Behdad says, this is not a human language, and we shouldn't trade
internal structural consistency and consistency *within* glib for
whatever consistency with other frameworks (which is clearly less
important than internal consistency).

ciao,
--mitch