[Cuis-dev] FileMan and FileStream?
Ken.Dickey at Whidbey.com
Mon Dec 21 15:48:03 CST 2015
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.
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'.
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:
> 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...
More information about the Cuis-dev