Jeremy White wrote:
Brian Millham skin email on the users list has highlighted something
that I've been thinking about for a while - how to make creating
Win32-GUI classes easier/safer.
One of the problems creating a Win32-GUI class is were to store the
instance data for the object while allowing the events to have access to
this data.
In the current version of Win32-GUI you can stuff data into a structure
and store it via the window with the UserData method, and then retrieve
it in the event handler:
[snip]
This works well, but there is huge scope for clobbering the data if this
approach was used for a formal class. Ok - in the class documentation
you could mention that the instance data is stored as a hash, and if you
need to store data via UserData you should use your own key - but I'm
wondering if there is a better way to handle this? For example, we could
add a "Data" method which could be used to store instance data, leaving
the UserData method free for the user?
I've been thinking about this for some time too. My view is that
'UserData' should be just that, for the script writer to use. Modules
should have somewhere else. Inheritance causes problems, as each level
in the inheritance chain may want to store some instance data, without
clobbering any other layer.
How about something like this:
- The 'userdata' member of the (internal) stored data always holds a
hash. The UserData method stores the passed SV in the 'UserData' member
of that hash.
The 'Data' method stores the passed SV in the hash with a key equal to
the current classname (obtained from ref($_[0])). As you can't have 2
classes with the same name in an inheritance hierarchy, nothing ever
clobbers anything else.
This would be problematic if you ever wanted access to your instance
data from a different package from where you set it - but you really
should be using accessor methods to do this anyway.
Does this work, and is it sensible?
Regards,
Rob.
