[XML-SIG] Re: [4suite] ReleaseNode interface in 4XSLT

[Martin v. Loewis]

>   Putting such a method on the node makes the most sense, if the
> method makes sense at all.  This allows different classes within an
> implementation to do the right thing without the dispatching overhead,
> and makes the most sense for implementations which can be subclassed.

I agree. Making it a non-method is a suggestion you might get from a
C++ programmer; the C++ equivalen - "delete this;" - bad style since
you might run a method of the object that is being destroyed. Of
course, in Python, this is not a problem.


>   I am a little concerned about the method, however, because I see two
> different possibilities.  One is the "I don't need you anymore; don't
> bother me" option (equivalent to DECREF), and the other is "Break all
> your internal links and die", equivalent to the minidom .unlink()
> method.

I can't understand the value of the first option. If you don't need an
Element or a document anymore which somebody else might be holding
onto, you can just drop it, right?

> From the discussion so far, I'm getting the sense that the
> latter is what is being discussed, and this is not always
> appropriate.  To build DOM trees to use with the XPath/XSLT engines,
> would I need to provide an empty .releaseNode(), since the DOM trees
> are persistent and have lifetimes far beyond the individual use for
> them with a specific transformation?

Not necessarily. Currently, 4XSLT uses ReleaseNode e.g. to release a
style sheet, in a data flow:
- read the style sheet using the StylesheetReader from an XML document
  (i.e. a byte stream)
- process the style sheet
- release it

Another application is with result tree fragments: when instantiating
an element, nodes get cloned over and over, and temporary results need
to be released.

There may be also cases where 4XSLT releases elements it did not
create; I'd consider that a bug.

I don't think we should introduce explicit reference counters for
documents or some such; we should strive for less memory management,
not more.

Regards,
Martin