You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by bu...@apache.org on 2001/10/05 20:43:07 UTC
DO NOT REPLY [Bug 1405] -
Extension function can not return the same Node object
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1405
Extension function can not return the same Node object
------- Additional Comments From keshlam@us.ibm.com 2001-10-05 11:43 -------
If you're talking about Node objects, you're talking about the DOM API. The DOM
has not yet really defined how Node Identity is tested, but in almost all DOM
implementations -- including our DOM layer -- if two node references have the
same object identity they _DO_ represent the same node.
The folks working on the DOM spec are developing a way to handle cases were two
references that do not have object identity still refer to the same node (as is
possible in our DOM proxyng environment), via the isSameNode() test in DOM
Level 3. I don't believe anyone has considered the case of a single object
changing which node it refers to; once you permit that, all the assumptions of
object-oriented programming break down.
So I think the right answer here is to not reuse the Nodes you're returning. You
certainly may be able to reuse most or all of the data storage behind them, if
you're sure you will never again refer to the previous node... but you should
probably implement a "flyweight" DOM-compatable proxy object for each Node you
deliver.
The advantage of a standard API is that it lets you plug in other
implementations. The disadvantage is that you have to conform to the behaviors
specified by that API. I think this ones on the wrong side of the line; the
optmization achieved is minimal and applies to an uncommon case, and the
architectural disruption is significant.
I suggest we either declare this Invalid, or knock it down to Enhancement since
what you're really asking us to do is accept a non-DOM node model.