[Xcb] Reply Buffering Question

[Anselm R. Garbe]

Hi,

On Tue, Nov 20, 2007 at 10:08:45PM -0800, Barton C Massey wrote:
> In message <20071120095515.GA22307 at suckless.org> you wrote:
> > As C programmer I pretty much dislike the namespace
> > concept, at least in C++ (in Java it seems acceptable to
> > me, with Haskell I have no experience, so I can't argue
> > about Haskell). The reason for this is quite simple. Due
> > the fact that C does not support namespaces, the average C
> > programmer is enforced to keep the amount of exported
> > functions small and to think about the interface
> > carefully. Hence, I believe no namespaces enforce simple
> > and sane interfaces.  So the language limitation lead to
> > an advantage in this regard.
> 
> I have to respectfully disagree here.  "You can write
> Fortran in any language"; Microsoft and others were writing
> horrific APIs with horrific names in C well before anybody
> had ever heard of C++ or namespaces.  I want the tools to
> manage documenting, architecting and cleaning up APIs; C
> fails to give me these tools.  In fact, Pascal's tools were
> far better.

I agree that the Microsoft C APIs are horrible, but I won't
consider them as a good source. I prefer the work by the C
inventors for themselves from Bell as a good source, or many
parts of the Linux kernel.

> I'm certainly not going to waste time defending C++; if you
> want to see how *I* think namespaces should have looked in a
> C-like language, hit http://nickle.org.  Those namespaces

I will have a look.

> > Why not using x_ as prefix? Xlib uses X, so x is free. And
> > it is implicit that XCB are C bindings, so I see no need
> > to introduce the 'cb' in C source code.
> 
> Because when I chose the prefix, we were using camel case
> instead of the current convention, so it would have been
> totally ambiguous.  It's too late for another great
> renaming, IMHO.  Besides, I think having a "brand name" on
> there is not horrible marketing; everybody can see where
> things come from that way.  Do we really want another thing
> called "X"?

Fair enough.

> > iterator = xcb_input_list_input_devices_devices_iterator(reply);
> > 
> > This function name has several flaws, which have nothing
> > todo with C limitations.
> > 
> > xcb_            -> I'm fine with this prefix, even if I'd recommend simply x_
> 
> > input_list_     -> is such verbosity really necessary? Lists are such a central
> >                    concept in C structures, that they are omitted usually in
> >                    type names.
> > 
> > input_devices_  -> I'm fine with this
> 
> You've mis-parsed it.  It's xcb_, then input_ because it's
> part of the input extension, then list_input_devices (the
> name of the request, as pulled from the Xinput
> documentation).  If it was in a nested namespace
> 
>   xcb.input.list_input_devices

Well ok, another idea would go into a different direction. If
you really want to encapsulate things with C in a
namespace-similiar manner, why not encapsulating the functions
of the interface using structs consisting of certain levels of
function pointers and modules?

typedef struct InputDevice InputDevice;
typedef InputDevice * InputDeviceIter;
struct InputDevice {
	void *data;
	...
	InputDevice *next;
};

typedef struct {
	InputDeviceIter (*iterator)(const char *);
	InputDevice *devices;
} InputExtension;

typedef struct XCB XCB;
struct XCB {
	InputExtension input;
	...
};

InputDeviceIter 
iterator(const char *reply) {
	...
	return NULL;
}

InputDeviceIter 
next(InputDeviceIter it) {
	if(it.next)
		return it.next;
	return NULL;
}

void
xcb_init(XCB *xcb) {
	/* init function pointers */
	xcb.input.devices.iterator = iterator;
	...
}

This way one would have:

XCB xcb;
InputDeviceIter iter;

xcb_init(&xcb);
iter = xcb.input.devices.iterator(reply);

Well, this is just a quick'n'dirty example how one could make it
look like in a modern language with C. I know that the
xcb_init() call is somewhat cumbersome, but apart from this,
nothing else must be done.

> this confusion would never have arisen.  As an added bonus
> the prefixes would normally be dropped because of imports.
> Add on some reasonable ADT support (objects or otherwise),
> and you end up with the quite reasonable-looking
> 
>   list_input_devices.devices_iterator
> 
> in a modern language.

Well, that's possible with C as well, see above.

> Not really. We can construct an iterator for each kind of
> aggregate in the reply record from a given request.
> Omitting the fact that this function produces an iterator
> seems unwise; omitting the fact that it iterates the devices
> would mean a different naming convention for replies that
> have more than one kind of thing they can iterate over,
> which means that you'd have to guess or look up everytime
> you tried to type a name.

Honestly, I dislike the applying the iterator concept in C, this
hasn't been done in traditional C code, structs had prev/next
pointers for iterating a list usually. People who came from OO
languages to C attempt to export their design patterns to C.
But that doesn't work out so well, as we notice it in this
discussion here. 

But I agree that iterators seem acceptable in the XCB context to
me.

> In other words, the guiding principle is that one should be
> able to *infer* the name of the routine they want to call
> without reference to any documentation other than the
> protocol spec.  I think these long names are about the best
> we can do with this.

Compared to my above solution I agree on this. At least long
names tend to provide a flat, hence simple, interface. But I
still see chances that there is much potential for
simplification. I hope I get some freetime soon that I can come
up with something for a further, more detailed discussion.

> BTW; I really should write this stuff down before it comes
> up on this list, but I'm lazy.  Thanks for starting the
> discussion.

Hehe...

Regards,
-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361