[Xcb] obj-xcb questions

[Jamey Sharp]

Hi Thomas! We seem to be on mostly the same page, just hashing out the
little details. That's a nice place to be. :-)

On Mon, Jun 12, 2006 at 09:30:27AM -0700, Thomas Coppi wrote:
> Jamey Sharp wrote:
> > I'm not sure Create* requests should be invoked from constructors for
> > their XID types. At the least, you have to allow constructing a window
> > object from an existing window ID without having CreateWindow called on
> > it, for example. (The window ID might have come from QueryTree, say.)
> > You might also consider allowing a particular window ID to be used in a
> > CreateWindow, then DestroyWindow, then another CreateWindow -- I believe
> > the protocol allows that, although it's probably unwise and confusing.
> > Anyway, letting CreateWindow be just another method in ObjXCBWindow
> > might make sense.
> 
>  Well, this can certainly be done.  I can have two constructors
> ObjXCBWindow, one that doesn't take an xid argument and creates its own,
> and another that takes in an XID, and likewise for other objects where
> it makes sense.

Yeah, that addresses an important point, but I was asking more about
when requests like CreateWindow are issued. Just to sanity check: you
understand that for WINDOW, there's both XCBWINDOWNew and
XCBCreateWindow, and you have to call both to get a window created,
right? The first allocates the XID on the client side, and the second
tells the server to associate that XID with a server-side window
structure. Same goes for all the XID types. I'm suggesting that apps
might want to keep these separate, maybe.

> > I'm concerned that you don't seem to be planning to support latency
> > hiding in any way. ...
> 
>  I left out the most important part of XCB :(

Heh. No harm done. :-) Actually, having built a few libraries on top of
XCB now, I think it's interesting how tricky it is to design APIs to
allow high-level latency hiding. I suspect most programmers don't have
much experience thinking asynchronously.

> > If you're going to return XCB types from these functions, I think it
> > should be the cookie types, not the reply types. If you want to
> > return reply objects, I think they should be real objects with
> > accessor functions that only force the cookie when accessed.
> 
> Returning a new object with accessor methods makes the most sense to
> me, as then the caller wouldn't have to deal with direct XCB calls by
> himself.

Also, even XCB itself effectively has accessor "methods" for iterators
on variable-length parts of responses. Wrapping that in an object makes
sense to me.

A mixed approach could work too though. The object you return might have
one accessor for returning the XCB*Rep structure. That's a more
object-oriented version of XCB's cookie model, but allows fast direct
structure access after the cookie has been forced. On the other hand, it
may turn out that the mixed approach would prevent use of garbage
collection for the replies, and there aren't very many fields in any
reply, and I don't think apps are ever limited by the speed they can
access reply fields. So this may be a bad idea. :-)

> > Also, I don't see that you've considered error handling yet, so I want
> > to bring it to your attention. Objective-C supports exceptions, right?
> 
>  It does support exceptions, however they are an extension created by
> Apple and only supported on GCC 4.0 and above with the GNU runtime, or
> on GCC 3.3 and above on OSX.  I'm not so sure about coding to such a new
> feature, but it could always be #ifdefed out and fallback if gcc4 or osx
> isn't detected.

I guess I tend to think of "object-oriented" and "exception support" as
going together, so I just assumed... :-)

It seems to me that users of your library need to be able to assume
either that it throws no exceptions, or that if no exception is thrown
then everything is OK. In other words, I think you have to commit either
to not using exceptions or to using them everywhere, respectively.
Anything else seems confusing, like how the C++ 'new' operator can
either return null or throw an exception in low-memory conditions,
depending on the implementation.

So I don't know whether you should require the newer GCC versions or
avoid exceptions, but I don't think going down the path of #ifdefs is a
good idea.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060612/a8efd6d8/attachment.pgp