[Xcb] about api changes

[Christoph Pfister]

Hi,

Am Mittwoch, 6. Juni 2007 22:01 schrieb Thomas Hunger:
> Hi,
>
> > - iterator "mess" (e.g. quite some duplication of code for those
> > iterators which just point to an entry in an array; maybe only
> > having iterator_t *xcb_...s() and int xcb_..._length() for that
>
> I could not find anything in the archives about this. Do you have a
> pointer or maybe a few examples?

Hmm - likely I had those thoughts during some irc discussion. Examples are 
xcb_depth_visuals, xcb_setup_pixmap_formats, ... Maybe some other iterators 
also fall under this category - dunno.

> > type of iterator), ".rem" is named +/- well
>
> See:
> http://lists.freedesktop.org/archives/xcb/2007-February/002570.html
>
> My vote is for .remaining (or anything, but a full word)

Ideally (at least imho) we wouldn't have those iterator structures anymore 
(okay - this might be a bit heavy for an api breakage), but instead elements 
with adjacent memory positions where possible (/me has to investigate a bit 
there and look how realistic that would be).

> > - some points about naming normalization
>
> I'd like to have one change: currently we convert e.g.
>
> "CHAR2B" to "xcb_char2b_t"
>
> but name="data2" will become
> xcb_glx_vendor_private_with_reply_data_2
>
> For consistency I think we should either
> a) Always have numbers stick to the previous word (handle them as
>    lower case letters) or
> b) Always separate them (e.g. xcb_char_2_b_t)
>
> I vote for a).

I think numbers should be generally avoided - but yes, I also think that 
having them separated looks a bit strange (there may be single cases which 
need special treatment though ...).

> > - should the _request stuff be part of the public api? (e.g.
> > compile time speedup if the headers are smaller)
>
> Maybe we could collect Ideas in this thread and put the ones we agree
> on into the wiki?

I'd say put them on the wiki early (and maybe have different opinions there) 
as I think it can get quite chaotic with lots of mails ... But of course the 
actual discussion should happen via mail - just that sometimes poeple can't 
read up immediately and so the wiki page as a current-state-of-discussion may 
help :)

> Tom

Christoph