PROPOSAL: Add openFileTemplate,
openBinaryFileTemplate to System.IO
marlowsd at gmail.com
Mon Aug 3 11:45:30 EDT 2009
On 25/07/2009 13:35, Ian Lynagh wrote:
> On Fri, Jul 24, 2009 at 11:11:40PM -0700, Evan Laforge wrote:
>> On Fri, Jul 24, 2009 at 11:02 PM, minh thu<noteed at gmail.com> wrote:
>>> 2009/7/25 Evan Laforge<qdunkan at gmail.com>:
>>>> I've never heard this usage of the word "template" before, so I
>>>> guessed it was meant to open some kind of template file.
>>>> openWithMode? openWithPermissions?
>>> man mktemp
>> Ohhh, it's for the filename, sorry, all the talk about permissions got
>> me on the wrong track.
> Right. Just to clarify for anyone else reading, we currently have:
> openTempFile :: FilePath -> String -> IO (FilePath, Handle)
> openBinaryTempFile :: FilePath -> String -> IO (FilePath, Handle)
> which mask the mode, and we would add
> openFileTemplate :: FilePath -> String -> IO (FilePath, Handle)
> openBinaryFileTemplate :: FilePath -> String -> IO (FilePath, Handle)
> which do not.
> Theese functions are used like this:
> openFileTemplate "/foo/bar" "bazXXX.ext"
> and open a file called "baz143.ext". "bazXXX.ext" is the template.
I'm not too keen on the naming. openFileTemplate differs from
openTempFile only in that it uses the default permissions, and yet its
name suggests that it does something quite different.
The fact that you don't know what the file is going to be called means
that the API is only really useful for temporary files, so I have no
problem with that being part of the name. Perhaps
Or perhaps we deprecate openTempFile, and make a new openTemporaryFile
that takes a Bool argument to say whether to make the file private or not?
More information about the Libraries