Re: Arbitrary Data Ptr Attribute For Node?

On Sun, Jul 29, 2001 at 04:03:22PM +0930, Peter Kelly wrote:
> >>>In practice shouldn't Node have a void */Object attribute on which to
> >>>
> >>This is a very timely subject!  The working group will meet next week, and
> > 
> > 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.
> 
> This will cause problems in languages such as C++, as how will you know
> when to delete the object that is pointed to? You would have to

There would be a user defined semantic specific to the application. This
is actually quite common. See man menu_usrptr (3X) from the curses
library. The mechanism would likely be to simply free all userPtrs when
any node is deallocated. Or it might be decided based on attributes of
the node or userPtr itself. The burden here is that you must traverse
each node of the branch and deallocate each userPtr explicitly.

> maintain a list elsewhere of what nodes have what pointers so you know
> when they are not being used, defeating the purpose of having the pointer
> stored in the node in the first place. The other alternative is to have
> either memory leaks or potential for crashes.

Maintaining a separate list of these pointers would be perfectly
reasonable. This would not defeat the purpose of the userPtr. The userPtr
would not be for storage as much as access. By associating the data with
a node you can access it based on the hierarchial stucture of the DOM
tree itself.

Not deallocating the userPtr is not an alternative.

> While this feature may be useful in some languages (e.g ECMAScript), I

Actually, I don't believe it would be of much use to ECMAScript. It would
be of use to applications that use the DOM for storing and organizing
state outside of the original XML/HTML content. For example, an MVC
application might use the DOM as it's Model. As such it is required to
contain *all* of the data associated with the Model. The Controller and
View are not allowed to communicate data because any new Views should be
able to extract *all* data from the Model and not have to worry about
interfacing with the Controller. In this case the DOM is being used as
a data store and convievably it might be used to hierarchially organize
transient state that was not defined in the XML or HTML source.

But of course the userPtr might be used for anything.

> believe it would cause too many implementation problems in languages
> that require explicit memory allocation/deallocation.

The only reasonable solution is to simply define the userPtr without any
facilities to manage it. Anything more would indeed lead to implementation
problems (in fact I do not beleive a portable interface could even be
defined). Adding a void *userPtr member to Node is of course trivial.

Mike

Received on Sunday, 29 July 2001 23:57:45 UTC