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.