Re: Efficient read-only cloning?

John Cowan <cowan@locke.ccil.org> writes:

> Joe Kesselman scripsit:
> 
> > EntityReference is supposed to (appear to) contain a read-only copy of the
> > data stored in the Entity. I'm looking for a more elegant method of
> > achieving that.
>  
> I don't think you can, really.  The children of an EntityReference
> can't be the same objects as the children of an Entity, because of
> the Node.getParent() method, which must return a different result
> in each case.  If you can figure a way around this problem, your
> other problems are fairly straightforward.

I suspect that the solution may be to note that, as far as I can tell,
nothing in the specification says that the parent of these ``virtual
children'' has to be the EntityReference node.  It could, in fact, be their
``real'' parent, the Entity.

This makes traversal harder, of course, but only because TreeNodeIterator is
no longer in the spec.  Nothing prevents an implementor from defining it
locally, however.  As far as I can tell the only other alternative is to
(perhaps lazily) copy the children.

I note in passing that Node does not appear to have a ``readonly''
attribute, so that the only way to determine whether a Node is readonly is
to attempt to modify it and see whether that throws an exception.  This
seems like an oversight.

In my opinion, having Node.getParentNode in the spec is a serious mistake,
since it rules out implementations that share structure.  But nobody asked
me.  Maybe it can be made optional in Level 2.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Wednesday, 23 September 1998 12:51:20 UTC