[erlang-questions] [eeps] EEP 9
Sat Mar 8 18:45:38 CET 2008
I agree that the proposal below would make for more readable code
(although the difference between split(Buffer, "\n ") and
split(Buffer, [<<"\n">>,<<" ">>]) is not really all that big). A
potential problem is that it could lead to confusion and strange
errors if you intended to write <<"and">> but instead by mistake wrote
With the proposal below the following two functions will be very
similar but will return very different results:
split(<<"cat and dog">>, "and") -> [<<"c">>,<<"t ">>,<<" ">>,<<"og">>]
split(<<"cat and dog">>, <<"and">>) -> [<<"cat ">>, <<" dog">>]
Confusing the two would be easy if you are not sitting with the ref
manual open all the time.
Seems like we need both a function similar to string:tokens/2 (which
could take a list of one char separators, like "and" above) and a
split_with function which takes a binary or a list of binaries. Maybe
the examples above aren't all that great, but consider for instance
the difference between "\r\n" and <<"\r\n">> when splitting headers
according to RFC822.
Which other functions where you thinking about?
On Sat, Mar 8, 2008 at 4:34 PM, Vlad Balin <gaperton@REDACTED> wrote:
> One more issue. Take this function as an example.
> split(Binary, SplitKeys) -> List
> Binary = binary()
> SplitKeys = binary() | [binary()]
> Wouldn't it be useful to allow integers in SplitKeys in place of
> binaries? We can treat them as 1-byte binaries (should be easy to
> implement), and it will make code more readable in cases when keys
> consist of 1 character.
> With this option, we can just write
> split( Buffer, "\n " )
> instead of
> > binary:match(<<"hello, world\n">>,[<<"\n">>,<<" ">>]).
> It can be applied to many functions in this module, and it should
> increase code readability in general.
More information about the erlang-questions