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

[Joe Armstrong]

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
>
>