[Xcb] Renaming errors: XCB* -> XCBBad*

[Jamey Sharp]

On Fri, Apr 28, 2006 at 04:01:26PM -0700, Ian Osgood wrote:
> I had initially defined enum XCBAccess { Disabled, Enabled } for  
> SetAccessControl.  This conflicted with the error #define XCBAccess.  
> ...
> As for the enumerations, we never actually use the typedefs, so it  
> seems like needless namespace pollution.  (Although I can imagine  
> eventually annotating the protocol definitions to indicate that  
> particular fields take particular enumerations or special xid values.)

#defining it may have been a bad choice anyway, and naming the
enumerations may have been a bad choice as well. We can put the enum
names back later without breaking backwards-compatibility, but we can't
take them away, so I don't mind removing them now even though there may
be a use for them later.

> I solved the immediate problem by renaming the enum to  
> XCBAccessControl.  However, I still think the names for the error  
> codes are too generic.  For instance, there is nothing in the name  
> "XCBValue" or "XCBCursor" that indicates that it is an error code  
> rather than some other entity.

We have inconsistent naming across the extensions as well. (This may be
one of those ABI bugfixes I'll allow between 0.9 and 1.0.) shm.xml has
"BadSeg", while sync.xml has "Counter" and "Alarm", and glx.xml prefixes
all names with "Bad" except one named just "UnsupportedPrivateRequest".

The XML shouldn't have "Bad" in any of the error names, I think, which
is independent from whether "Bad" should appear in the generated code.

I guess consistently generating the name "Bad" in the C code is a naming
translation rule that programmers will be able to learn without too much
trouble. So I guess I'm not opposed to the naming change.

> (BTW, why do we have a separate typedef for each error response when  
> they are all essentially identical?)

That's a fine question, but I think the answer is reasonable. All the
names appear in the protocol spec, so it seems important to have the
names appear in the API too. Otherwise, the programmer has to remember
that the structure of the XCBIDChoice error is XCBValueError, but the
XCBName error is XCBRequestError: I can probably learn that, but I can
think of more interesting things to memorize.

A hypothetical X12 might use identical error codes for identical error
structures, and have some other way of identifying the precise cause of
an error. We don't have X12, and possibly won't ever since X11 is good
enough. Oh well.

--Jamey

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060428/29789f69/attachment.pgp