Re: Arbitrary Data Ptr Attribute For Node?

On Sat, Jul 28, 2001 at 09:23:18AM -0400, Mike.Champion@SoftwareAG-USA.com wrote:
> > -----Original Message-----
> > Michael B. Allen
> > Sent: Saturday, July 28, 2001 4:47 AM
> > 
> > In practice shouldn't Node have a void */Object attribute on which to
> > hang user data? I'm writing an ncurses, DOM, MVC thingy and in order
> > to communicate keystrokes from the controller to the form components
> > in the view through the DOM model it's obvious that a data pointer is
> > necessary. Or did I miss something?
> 
> This is a very timely subject!  The working group will meet next week, and
> this is on the agenda.  I personally agree that we need a standard interface
> to attach a pointer / reference to arbitrary data to a DOM node.  The
> working group proposed a DOMKey mechanism to make it easy for applications
> to maintain an external mapping between DOM nodes and arbitrary data, but
> this has proved unworkable.  
> 
> I believe the main objection to an arbitrary data pointer is that it would
> be difficult to guarantee that a DOM implementation would "do the right
> thing" when a node is cloned, destroyed, etc.  Anyway, anyone wanting this
> feature in Level 3 should make their strongest case for it immediately!

Well, I have since realized that Events should be used to solve my
immediate problem, however I can contribute my opinions on the issues
you mention above.

Deallocation is of course specific to languages that require explicit
management of memory and adding an interface for it would be unecessary
for other languages such as Java, ECMA Script, etc. I believe it is
good coding style to deallocate memory at the same API level and nearby
the code that allocated it. I would rather have the functionality and
be required to traverse a tree to deallocate these userPtrs than not
have the functionality at all. In practice, I could imagine it may not
even be necessary to deallocate them through the DOM tree. They may be
referenced elsewhere. One could easily maintain a linked list of these
poitners for just this purpose.

Cloning is more difficult. However, again I believe it can be left
to the user. I do not beleive there are any routines that implicitly
provoke cloning of nodes within the DOM. Callers are always directly or
indirectly responsible for cloning and therefore providing a semantic
for cloning userPtrs would be mearly a convienience operation.

IMHO a userPtr attribute should be added to Node interface without
facilties for deallocting or cloning them as these would only be in both
cases conienience operations.

Mike

Received on Saturday, 28 July 2001 16:08:04 UTC