[Xcb] about api changes
Barton C Massey
bart at cs.pdx.edu
Wed Jul 11 12:38:36 PDT 2007
In message <200707111841.36348.hto at arcor.de> you wrote:
> I just want to add a few examples to help a decision.
Excellent!
> Take e.g. the following struct from xproto.xml:
>
> <struct name="SEGMENT">
> <field type="INT16" name="x1" />
> <field type="INT16" name="y1" />
> <field type="INT16" name="x2" />
> <field type="INT16" name="y2" />
> </struct>
>
> If the current rename filter is applied it would result in
>
> struct {
> int16_t x_1;
> int16_t y_1;
> int16_t x_2;
> int16_t y_2;
> }
>
> If the rename filter is changed so that numbers are not separated we
> would have x1, x2, ... but some requests would look strange:
> "PolyText8" would become "poly_text8" instead of "poly_text_8" (the
> former looks strange to me).
Sounds like the rename filter needs to be special-cased for
[a-z][0-9].
> A completely different matter are enums. Some have items with numbers
> as names. E.g. <item name="1"/>. Currently the enum-name is always
> separated by an underscore.
>
> This behaviour would result e.g. in "xcb_button_mask_1" instead of the
> consistent "xcb_button_mask1" (the latter looks strange again).
I agree that the latter looks strange :-). Sounds like the
naming filter is doing the right thing here.
> It seems hard to be consistent _and_ good looking if we handle
> everything with the same filter...
IMHO the problem isn't so much consistency between function
names and field names. It's just getting the naming filter
reasonable.
One might also question whether it's worth breaking the API
over any of this: I'm in the camp of folks who thought the
pre-renaming scheme was fine, so I'm obviously the wrong
person to ask :-). Opinions?
Bart
More information about the Xcb
mailing list