[Xcb] Reply Buffering Question

[Anselm R. Garbe]

Hi Bart,

On Sat, Nov 17, 2007 at 03:24:17PM -0800, Barton C Massey wrote:
> In message <20071117171644.GE26472 at suckless.org> you wrote:
> > Long function names don't lead to bad code, they are. In the C
> > world we don't suffer from them so much historically spoken,
> > because C programmers tend to use snappy but well-choosen names
> > for functions. Well, but as a bad example see this[1](*):
> > 
> > In The Practice of Programming (which is a MUST for any C
> > programmer) a whole chapter has been written about naming
> > conventions, which has heavily influenced the C world since the
> > 80s. And I agree on them, they are some good examples in
> > contrast to the other link.
> 
> Long function names aren't crappy code in this case, they're
> the result of a crappy programming language.  In C++ (which
> don't get me wrong, I absolutely abhor in general), Java, or
> Haskell we would use namespaces and scoping to clean up most
> of these ludicrously long names.  In C, we're stuck with a
> single flat namespace for programs that may require a
> zillion libraries that need to be extensible, so we do what
> we can.  The C world hasn't suffered from this so much
> historically, because there hasn't been much out there in
> the way of things to collide with, and APIs have been kept
> small, so name choices have been fairly free.  Modern X
> negates both these advantages.

As C programmer I pretty much dislike the namespace concept, at least in C++
(in Java it seems acceptable to me, with Haskell I have no experience, so I
can't argue about Haskell). The reason for this is quite simple. Due the fact
that C does not support namespaces, the average C programmer is enforced to
keep the amount of exported functions small and to think about the interface
carefully. Hence, I believe no namespaces enforce simple and sane interfaces.
So the language limitation lead to an advantage in this regard. If you ever
worked with C++, you will agree on the pain to identify which namespace is
currently used or not used (because some jerk declared using namspace whatever
in some header file!!!). 

And if one really needs namespaces in C, there are ways to aim them in
conjunction with some CPP macros, however I won't recommend that for the above
reasons.
 
> I think it's horrible that all of our public functions start
> with xcb_ to begin with.  The fact of the matter is that my
> principal criterion in choosing that name is that it was a
> short collection of random constants that was unlikely to
> collide with somebody else's prefix---and I was wrong.  It
> also stands for X Cut Buffer.

Why not using x_ as prefix? Xlib uses X, so x is free. And it is implicit that
XCB are C bindings, so I see no need to introduce the 'cb' in C source code.

> I'd rather see too-long names than random abbreviations,
> random prefixes, misspellings, elided vowels, ambiguous
> names, sets of names that "you just have to know" go
> together.

I agree on the problems you address here, except the conclusion to prefer long
names. Let's bring the function name into focus I considered crappy:

iterator = xcb_input_list_input_devices_devices_iterator(reply);

This function name has several flaws, which have nothing todo with C limitations.

xcb_            -> I'm fine with this prefix, even if I'd recommend simply x_

input_list_     -> is such verbosity really necessary? Lists are such a central
                   concept in C structures, that they are omitted usually in
                   type names.

input_devices_  -> I'm fine with this

devices_iterator -> That's also very verbose.

How about

  it = x_input_device_iterator(reply);

in this case. An iterator already makes sure that it is a list or array. In
conjunction with the term input device it is clear that there might be more
than a single device, but each iterator points to a single input device. This
is much more readable in my opinion. I know that it might be hard to generate
this function name from an XML spec, but it seems possible.

Regards,
-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361