[erlang-questions] proposal: expand definition of filename type

[Paul Mineiro]

The point is well taken generally, but for iolists in particular, I find
that I'm often disappointed that various portions of stdlib only take
strings, since building up iolists incrementally is natural and many
useful functions (io_lib:format/2, mochijson2:encode/1) return iolists.
Example: you cannot use an iolist as the body of a request for
http:request/4 and friends.  I generally only discover empirically when
testing that I have to insert flattening code to make things work.

-- p

On Thu, 3 Sep 2009, Joe Armstrong wrote:

> Sorry James, but I disagree...
>
> I think the library arguments like this should be moved in exactly the
> oppose direction - I dislike polymorphic arguments like this. I think
> the first argument to  to file:file_open (or whatever) should be a
> string and nothing else.
>
> If you want polymorphic behaviour then you should define you own
> private interface library
> james_lib:file_open/2 which defines whatever conventions you like for
> the arguments.
>
> The current practise of allowing polymorphic arguments is a symptom of
> "can't make your mid up ism" - it makes type checking a lot more
> difficult and the logic of programs a lot
> more difficult to follow. It make programming more difficult because I
> have to choose which convention to use, also it will trip me up later
> since I'll end up thinking that all filenames
> in all modules in every application can be represented in this way.
>
> To achieve what you want I suggest having a single and very large library
> james_hague_lib_misc.erl where you put a large number of unrelated
> functions that merely modify the behaviour of the standard functions.
> (this is what I did in the Erlang book and I have continued with the
> practise since then)
>
> I think the standard libraries should have a restricted number of
> types and that deviations
> from these belong in private libraries. If a particular set of
> customisations is useful then it can be published in its own right as
> a library.
>
> Cheers
>
> /Joe
>
> On Thu, Sep 3, 2009 at 5:36 PM, James Hague<james.hague@REDACTED> wrote:
> > I've found that sometimes it's handy to have filenames as lists--which
> > is the Erlang standard--and sometimes it's nice to treat them as
> > binaries.  So here's a proposal: In file access functions, define a
> > filename to be a binary or an IO list.
> >
> > Examples:
> > 1. file:file_open(<<"circus/images/clown.png">>, []).
> > 2. file:file_open([Directory, BaseName, ".dat"], []).
> >
> > Advantages:
> > * Filenames, which can potentially be long, don't expand into 8 or 16
> > bytes per character.  (Think of code that manipulates a huge directory
> > tree, for example.)
> > * It's easy to add path names and extensions without copying entire lists.
> >
> > Open questions:
> > * Just keep the filename module operating on lists?
> > * Should there be an alternate version of file:list_dir that returns a
> > list of binaries?
> >
> > Note that there shouldn't be any compatibility issues, because lists
> > are a subset of IO lists.
> >
> > ________________________________________________________________
> > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > erlang-questions (at) erlang.org
> >
> >
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>