Re: Gtk{Tree,List} replacement proposal

[Maciej Stachowiak <mjs eazel com>]

Havoc Pennington <hp@redhat.com> writes:

> Maciej Stachowiak <mjs@eazel.com> writes: 
> > Why do you think it's way too long? 
> 
> Because I don't feel like typing it.

Emacs has nice symbol completion if you use ETAGS.
 
> Wait, I'm using C++ now... ;-)
> 
> > I came up with some stats for Owen
> > a while back and there were a lot of classes in current Gtk 1.3
> > (30-ish total?) that have names longer than this, as long, or shorter
> > by no more than two characters (and no, it's not that heavily
> > overbalanced to the short end).
> > 
> 
> Two wrongs, right, etc.

I don't think any of the existing names are wrong. My point is that no
one so far has bitched about the horrendously long names in Gtk+ as
far as I have seen. People _have_ had trouble with some of the
abbreviations not being terribly clear - for instance I've seen people
ask what the C in CList and CTree means on several occasions. And I
definitely think that C is more obvious than the TL in TLView.
  
> I think clarity should certainly beat brevity if we're talking about a
> single function name, but a namespace with 200 names in it is
> different, because while yes you have to learn the abbreviation, 
> it's only one thing to learn which opens the door to 200
> easy-to-learn-and-type names. 

The reason for naming clarity is not only for the person writing the
code, but also for those reading the code. For instance, we could give
every Gtk+ type a unique 4-letter, and I'm sure people could learn
them all eventually learn all the names and become very fast at typing
Gtk+ code, the poor people reading the code would have a really hard
time understanding what's going on.

 - Maciej