[Cuis-dev] FileMan and FileStream?
pbpublist at gmail.com
Mon Dec 21 16:26:16 CST 2015
On Mon, 2015-12-21 at 13:48 -0800, KenD wrote:
> Hi Phil,
> Sorry, decades of writing code in Scheme, Lisp, and the like.
> I am so used to with-input-from-file and the like that I forget about
> usage patterns where a file is to be open for extended durations. I
> tend to use a database or some other form of persistent storage in
> these cases.
Not just extended durations, but also where the file opening and
closing may overlap/extend beyond of the lifecycle of the code it is
being passed into. (log file rotation where the logger doesn't
know/care what it's logging to, replacing a network stream with a file
stream mid-execution, many development/debugging use cases etc. where
the code using the stream doesn't care what the source/destination of
the stream is and/or the stream may not be a file)
> Perhaps a renaming would help.
> Rather than 'private', which has a special meaning in Smalltalk
> usage, such cases should be prefixed 'primitive', 'unsafe', 'base',
> or 'lowlevel'.
My preference would be to leave the names as they were since a lot of
existing code already uses them and it would create an unnecessary
incompatibility. If anything, shouldn't the new methods have clearer
names like #readStreamDo:? (#readStream: looks like a setter method
name). If we must rename them, how about 'base' or maybe 'raw'?
'unsafe' and 'lowlevel' seem misleading and 'primitive' would be be
overloading the term given Smalltalk primitives. I could definitely
see a comment being warranted in the old methods (i.e. #readStream)
directing people to the new ones as being preferred where they make
> A persistent storage API might be an alternate solution, but changing
> the prefix is simplest.
> Masashi, are you following this? What is your view?
> On Mon, 21 Dec 2015 14:04:11 -0500
> "Phil (list)" <pbpublist at gmail.com> wrote:
> > Ken,
> > On Fri, 2015-12-18 at 23:33 -0500, Phil (list) wrote:
> > > 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.
> > Perhaps a better way to state this just occurred to me and I
> > thought
> > I'd take one more shot at it:
> > One of the great features of streams is that they allow data flow
> > to
> > exist and be passed around independently of your control flow. By
> > limiting their use inside of blocks (i.e. essentially attempting to
> > mandate that they be inside the control flow), you are eliminating
> > entire classes of utility for them and effectively deprecate the
> > use of
> > files in those cases if you are successful. If you are not, you
> > have
> > these made private* methods defacto public or necessitated the use
> > of
> > some anti-patterns to undo the damage.
> > Lisp has long had a similar solution to the 'forgot to close the
> > file'
> > problem in the form of the with-open-file macro. It is quite
> > useful
> > *for the use cases in which it makes sense* but it does not attempt
> > to
> > eliminate the standalone use of file handles in all situations.
> > Making these methods private seems like a very bad idea to me...
> > Thanks,
> > Phil
More information about the Cuis-dev