[Xcb] naming convention (finished)

[Carl Worth]

On Wed, 20 Sep 2006 01:09:33 -0700, Jamey Sharp wrote:
> Though Keith, I don't think the mixed approach would require looking at
> documentation. The twenty-some functions that would have the xcb_ prefix
> are all clearly special, as none of them are pure protocol-encapsulation
> stubs.

Be careful to avoid codifying what is an obvious distinction to you as
a distinction that every user will be forced to learn. Inconsistency
like this just forces users to continue to have to consult the
documentation, and there's little comfort in the fact that the
inconsistency might have some logical basis.

As a quiz, which of the following inconsistencies in Xlib have logical
basis? And which of those (if any) are of practical advantage for the
user to have to keep in mind to use the API?

	Alloc vs. Create
	Get vs. Query vs. Fetch
	Free vs. Destroy vs Delete

(Of course, I'll pardon XCB for maintaining any of these that are forced
by the protocol---and I will delight in XCB fixing any of these that
don't also exist in the protocol.)

As for the prefix, my vote is for "xcb" over "x".

In addition to auditory confusion, I think it's also unkind to allow
applications to legitimately be using functions that are identical
other than a studly caps vs. underscore distinction. There's still a
plan in place for applications to be able to migrate incrementally to
XCB from Xlib, right?

Imagine the confusion evident in a question such as "Why is it that we
sometimes use XFlush and we sometimes use x_flush?"

The letter 'x' was overloaded even before the X Window System started
using it, (it is the first meta-syntactic variable after all---binding
it was a rather poor choice), so I think XCB can do itself a favor by
maintaining a distinct prefix.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060920/1ab1f8c9/attachment.pgp