Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!helios.ee.lbl.gov!pasteur!dent!davidh
From: davidh@dent.Berkeley.EDU (David S. Harrison)
Newsgroups: comp.windows.x
Subject: Re: Ok then, please add CLIENT_DATA in the future.
Message-ID: <22298@pasteur.Berkeley.EDU>
Date: 21 Feb 90 23:57:09 GMT
References: <8542@shlump.nac.dec.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: davidh@dent.Berkeley.EDU (David S. Harrison)
Lines: 38

In article <8542@shlump.nac.dec.com>, nick@deccan.dec.com (Nick
Tsivranidis) writes:
> 
> 	OK, so the moral of the story is that there is no CLIENT_DATA
> 	attribute in the widgets. Thanks for the many hacks, but I
> 	already have an association object that associates 2 kinds of
> 	things together (in this case widgets and objects). I was just
> 	looking for a better way to do this (use less memory and run faster).

Please be careful when you ask for a feature like this -- you might get
it!  It turns out most people assume you can implement this by adding
a pointer to the structure and forgetting about it.  Unfortunately,
this isn't sufficient.  Imagine you have a program composed of multiple
packages.  Each one would like to associate data with widgets.  Oops, 
with only one pointer field these packages will trounce on each other.
Some designers then react by adding more generic pointers to the structure.
Now these packages have to have some protocol for choosing which pointer
they use.  Further, those applications not using these associations
pay for the memory consumed in all cases.  Another alternative is adding
a list of generic pointers to the structure each keyed by some sort
of context identifier.  However, now the lookup of this information
is no longer a simple dereference but a linear lookup (albeit a short
one on average) and all widgets still have this linked list field even 
though information is rarely associated with all of them.  A common
alternative is to implement a hash table that looks up client specific
information given a reference to the widget.  It is not that much
slower than the linear lookup and only consumes memory for associations 
actually used.  We have now arrived full circle back to the current
implementation supplied by X: context tables.  I can imagine other
implementations that might be better but I don't think the added
complexity is warranted unless the association table is shown to
be the bottleneck in your application.  In any case, I don't think
the correct solution is to jump in and add a field to the core widget
structure.

			David Harrison
			UC Berkeley Electronics Research Lab
			(davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)