[Xcb] Thomas Coppi's Objective-C binding

[Jamey Sharp]

On Fri, May 12, 2006 at 04:10:52PM -0700, Thomas Coppi wrote:
> Jamey Sharp wrote:
> > On Fri, May 12, 2006 at 08:17:29AM -0700, Josh Triplett wrote:
> >> Some language bindings may well need to provide add-on functionality
> >> in order to fit well with the language.  For example, any language
> >> with a concept of lazy objects, which can get evaluated when accessed,
> >> should probably hide the cookie mechanism behind a call that returns a
> >> proxy object and forces the reply when it needs to provide the data of
> >> that object.
> 
> I'm not sure what is meant by a "lazy object."  Do you mean return an
> object that forwards all messages it receives to another "real" object
> that then gets the reply?

Josh was trying to give a definition of that phrase when he used it. :-)
We're borrowing terminology from languages like Haskell, where by
default an expression is evaluated only when its result is needed. In
the prototype Haskell binding for XCB, I took advantage of this to make
latency hiding transparent. In the following program, the InternAtom
call immediately issues the appropriate request -- but the program
doesn't block on the reply until its value is needed by the print call.

main = do
  atom <- InternAtom "WM_DELETE_WINDOW"
  print atom

I seem to recall that Alp did something similar in his C# binding, so
you don't have to be working in a lazy functional language to do it. But
in an imperative implementation you have to have accessor methods that
can test whether the reply has been forced yet before returning parts of
the reply: you can't use direct structure member access if you want to
make latency hiding implicit. So there's an efficiency cost.

> >> Similarly, I can imagine that in languages having a higher degree of
> >> type safety than C, the WaitForEvent and PollForEvent calls will need
> >> to figure out what event they have and construct the corresponding
> >> object, rather than returning an XCBGenericEvent pointer that requires
> >> casting.
> > 
> > This is probably a good idea, but quite tricky when dealing with
> > extensions. It may be impossible if the ObjXCB binding allows calling
> > directly down to XCB.
> 
> I don't think that exposing the xids inside the Objects is a good idea.
> That would defeat the purpose of an Objective-Oriented layer.

I think you'll actually have to expose the XIDs. Various kinds of XIDs
often get stored into properties on the server, and maybe get
stored/fetched other ways I'm forgetting at the moment. Also, XIDs
routinely need to be compared for equality or used as table-lookup keys
in client applications.

That wasn't my point, though. If you expose the underlying XCBConnection
pointer to the application, I don't think it's possible in general to
return a type-safe event object, because the application might have
completely bypassed ObjXCB to use a particular extension that ObjXCB
wasn't compiled with support for.

--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/20060512/71319ab8/attachment.pgp