[Xcb] Thomas Coppi's Objective-C binding

[Thomas Coppi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamey Sharp wrote:
> 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.
> 

Gotcha.  I think doing it this way is preferable, as it is less complex
from the client application's point of view.

>>>> 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.
> 

Alrighty, that makes sense.

Thanks for helping to clear things up.

> --Jamey
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEZU1PlU6kaExSKKoRAmgLAKDaUGiesHSKjqb56rPC6uSztNd4wACgvksp
q66tGl+pPM4ajhmFRKuy63Q=
=3fYT
-----END PGP SIGNATURE-----