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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list