On Fri, 2005-12-16 at 23:57 +0000, Julian Foad wrote:
> So it seems to me that the proposed ownership model:
>
> > * Streams which read from or write to an underlying object own that
> > object, i.e. closing the stream closes the underlying object, if
> > applicable.
>
> ... is not right. Firstly, all streams read/write an underlying object (apart
> from a trivial "null" stream); the important distinction is whether that object
> was pre-existing, and thus might well be required to continue to exist in a
> usable state after the stream has been finished with and closed. Secondly, I
> feel that more commonly the stream will be required not to own the existing
> resource, but I may be wrong about that.
>
> I couldn't find an example of a stream *needing* to take ownership of an
> existing resource. I think you mentioned one...
The case where the ownership model helps most is the "complicated
constructor" case. If I'm a function and my contract is to return a
stream, and I want to set up that stream by opening an APR file and
stacking three streams on top of it, I want the ownership model to be in
effect so that when the caller closes the returned stream, all of the
lower-level streams and the APR file are closed as well.
Streams built from APR files and streams which stack on top of other
streams are all building on top of pre-existing objects; there's no
realistic way to design them otherwise. But for some purposes, we still
want them to own the lower-level object. When we don't want that, an
ownership-breaking stacking stream is an easy workaround.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 17 07:52:03 2005