[Xcb] RFC: Altenum updates for xcb/proto

[Peter Harris]

Barton C Massey wrote:
> In message <eaa105840902250634k5f25e667i8809d5ad19c61db6 at mail.gmail.com> you wrote:
>> I'd like to avoid creating a whole plethora of new
>> single-entry enums (XCB_WINDOW_NONE, XCB_PIXMAP_NONE,
>> XCB_COLORMAP_NONE, XCB_CURSOR_NONE, XCB_ATOM_NONE,
>> XCB_FONT_NONE, and maybe even a few
>> XCB_extension_newtype_NONE).
> 
> Why?

Aesthetics was my first answer (Xlib, the protocol document, et al only
have "None", and <field type="WINDOW" enum="Window"> isn't immediately
clear), but that's a rather weak argument.

More practically, libxcb has issues with the implementation. You have
xcb_window_t as both an <xidtype> and an <enum>, and gcc dies with
"xproto.h:279: error: redefinition of typedef 'xcb_window_t'".

We could rename xcb_<enumname>_t to xcb_<enumname>_enum or similar, but
that would break any existing code that actually uses the enum types for
anything (not that I'm aware of any). Or, if we're mucking with enum_t
definitions, we could just toss them altogether and #define the
constants (since C chucks enum members into the global namespace anyway).

Alternatively, we could use a different name for the enum.
XCB_WINDOW_NONE_NONE? XCB_WINDOW_IS_NONE? XCB_WNDW_NONE?
XCB_NULLABLE_WINDOW_NONE?

Most of the other enums in xproto.xml are tied to a specific request (or
group of requests), and can be named after that request [group]. "None"
is a somewhat special value, in that it spans a wide cross-section of
the protocol (including a number of extensions), so there really isn't a
request [group] that the enum can borrow a name from.

> I'd really prefer having them.

Fair enough.

> They can be
> auto-generated, after all, and sooner or later someone is
> going to decide that XCB_RANDOMEXTENSIONTYPE_NONE is 17
> instead of 0 for some reason and we'll have a problem if we
> don't have them have unique names.

Unique names for non-zero None are a given, of course.
XCB_NOTIFY_DETAIL_NONE == 7, to pick the example from xproto.
XCB_RENDER_SUB_PIXEL_NONE == 5, to pick the extension example. I don't
think either of those conflict with the global XCB_NONE.

>  Further, in typed
> languages you'll need them anyway for typechecking (correct,
> Antoine?).

Hmm. Good point. Antoine added to the CC list.

> Thanks hugely for all your work on this.

Thanks hugely for taking the time to review this.

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://www.opentext.com/connectivity
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866