[Gtk-sharp-list] Associate user data object with a widget

[Chris Howie]

On Thu, Nov 26, 2009 at 6:37 AM, Chuck Esterbrook
<chuck.esterbrook at gmail.com> wrote:
>> The reason that the "user data" mechanism is marked obsolete is
>> because it's completely the wrong way to model something like this and
>> usually creates more problems than it solves.
>
> Putting a value in a hashtable owned by an object isn't much different
> than putting a value in a variable owned by the object. In fact, some
> languages like Python even store their object variables using a
> hashtable!

Comparing Python to a tag/data property is comparing apples and
oranges, see below.

> There are several GUI framework authors who think user data is okay
> given that GUI libs tend to have this feature including GTK+,
> WinForms, WPF and Silverlight. See also:
> http://stackoverflow.com/questions/1058635/common-uses-for-the-tag-property
>
> I've used this technique in other GUI libs without experiencing a
> single problem. It's just an alternate way to stash data in an
> existing object.

The main problems with this approach are type safety and collisions.
In the case of winforms, where each control has a Tag property, you
are making a decision when you use that property that you are only
ever going to use it for one thing.  This may be ok for you, but I
find it rather unsettling.  Especially in the case of an extensible
program, where you might be throwing controls around between host and
addin, who is to say who gets control of the Tag property?

Perhaps you might consider it paranoid, but I simply consider the
usage of general data properties on UI widgets to be bad design.  If
you must use a property, then subclass the widget.  You will not only
avoid any obnoxious data-control issues but you get a typed property.

I find that most uses of Tag in winforms is due to its complete lack
of any kind of MVC architecture.  If you write your own on top of the
winforms API (which I have done, and boy is it nicer to work with)
then your need for any Tag property vanishes in a puff of
proper-OO-design smoke.

And no, throwing random properties on a Python object is easy, but
it's still not a terribly good idea except for rapid prototyping.  You
are assuming that future versions of that class are not going to use
whatever property name you pick.  Granted you could come up with a
namespace prefix to avoid collisions, but it's still not a very good
approach.

My two cents...

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers