[Xcb] about api changes

[Jeremy A. Kolb]

On Wed, 11 Jul 2007, Thomas Hunger wrote:

> > I think that the bug here is that the XML naming filter
> > isn't currently applied to all names, which IIRC is (a).  I
> > think we should fix that first; I suspect it was inadvertent
> > rather than deliberate.  Hopefully Josh or Jamey (when he
> > returns in a few days) can correct us if we're wrong; we
> > shouldn't do anything IMHO until we hear from at least one
> > of them.
> 
> Ok. I just want to add a few examples to help a decision.
> 
> 
> 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).
> 
> 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).
> 
> 
> It seems hard to be consistent _and_ good looking if we handle 
> everything with the same filter...
> 
> 
> Tom
> 

I actually kind of like "poly_text8" but I also like enum_name_1.  I think
we can be allowed to treat enum names and functions differently.  
They should probably follow the same rules in the XML but they don't need 
to in the generated binding.

If we keep the convention consistent within the xml, the binding 
generation 
side can do whatever it wants and should be powerful enough to detect 
cases like the above.

But then again I have no idea what I'm talking about ;)

Jeremy