Greg Hudson wrote:
> 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.
Yeah, OK, that sounds reasonable. Maybe I was wrong to imagine that non-owned
would be more common. Sorry for the distraction and doubt.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 17 10:07:53 2005