[Cuis-dev] FileMan and FileStream?

Juan Vuletich juan at jvuletich.org
Sat Dec 19 06:26:33 CST 2015

On 19/12/2015 01:33 a.m., Phil (list) via Cuis-dev wrote:
> On Fri, 2015-12-18 at 19:18 -0800, KenD wrote:
>> On Fri, 18 Dec 2015 22:06:07 -0500
>> "Phil (list)"<pbpublist at gmail.com>  wrote:
>>> I could do something like that which will of course end up
>>> resulting in
>>> my creating helper methods that look suspiciously, exactly, like
>>> private*Stream.  The main argument I'm making is that accessing
>>> files
>>> via streams (which get passed around *a lot*... typically only a
>>> bit of
>>> top level code even knows or cares if it is a file) is a pretty
>>> common
>>> use case so why not just acknowledge it and make them public in
>>> name
>>> and usage?
>> FileMan is using what I would call a functional style which ensures
>> that a stream is closed.
>> -------------------------------
>> writeStream: blockWithArg
>>      "If the file already exists raise FileExistsException.
>>       Creates the directory if it doesn't exist."
>>      | stream |
>>      stream := self privateWriteStream.
>>      [ blockWithArg value: stream ]
>> 	ensure: [ stream ifNotNil: [ :s | s close ]]
>> -------------------------------
>> Passing in a block which takes a stream argument is a natural style.
>> Forgetting to close a stream is also, IMHO, natural.
>> Don't use private* and you don't have the problem to worry about.
>> It has been designed out.
>> I think we should remove the bulk of the private*Stream uses.
> That argument is fine if you are writing file-centric code.  I'm
> talking about stream-centric code where one or more of your streams
> could trivially be (up until this change) file-backed.

But if they were files, they would need to be closed, right? So your 
stream-centric code needs to know about the differences between file 
streams and other streams.

I'm pretty sure you don't agree with this. So:

Can you point to a specific example? Discussion will get much easier then.

> Turning things
> inside out is far from convenient or even desirable (and possibly in
> some cases nearly impossible without convolution of the control flow)
> when what you really need are streams and are prepared to deal with
> them as such.
> I'm not arguing against the *Stream: methods as they are a better
> solution for the use cases in which they make sense.  It even makes
> sense to point people to them for many/most situations.  I am arguing
> for public *Stream (i.e. currently named private*Stream) methods as
> there are valid use cases for them.

Ok. Please point to an example (include the code in the email if needed) 
and let's take it from there.

Juan Vuletich

More information about the Cuis-dev mailing list