[erlang-questions] Must and May convention

[Dmytro Lytovchenko]

In older and more advanced languages this is done with function attributes.
They don't interfere with naming, and are available for IDE and for
compiler to see. Something like:

attr([throw]) fun read_file(Arg) -> ... exit(file_not_found).
> attr([nothrow, ok_error]) fun read_file2(Arg) -> {error, file_not_found}.


2017-09-27 11:25 GMT+02:00 Attila Rajmund Nohl <attila.r.nohl@REDACTED>:

> 2017-09-27 11:08 GMT+02:00 Joe Armstrong <erlang@REDACTED>:
> [...]
> > This turns out to be very convenient - I read many files
> > in my programs, so it's nice to know that must_read_file
> > will print a nice error message and terminate
> > if I give it a bad filename.
> >
> > Note: I can get the program to crash by writing
> >
> >    {ok, B} = file:read_file(F)
> >
> > But I don't get a nice error message telling me the filename.
> >
> > Any takers?
>
> My problem with all kinds of very common prefixes is that it breaks
> function name autocompletion. Or at least makes it harder to use when
> I have dozens/hundreds/thousands of function names starting with the
> same 3-5 characters - either I have to type those 3-5 characters all
> the time plus any more characters to find unique prefix for
> autocompletion or have to autocomplete twice (one for the may/must
> difference, one for the actual function name). Eclipse (for Java)
> helpfully shows the method signature including return value and thrown
> exceptions - I think this problem should be solved by the IDEs and not
> by naming conventions.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170927/d797f6b9/attachment.htm>