[erlang-questions] Re: atoms used as status info, 'constants' etc

Amit Murthy amit.murthy@REDACTED
Tue Aug 18 10:41:34 CEST 2009

Maybe tangentially relevant here.

Whenever I have a large number of constants of the same type, which I would
have defined as an enum in
some other language, I just define a record for the same.

For example,

-record(myerrors, {ok, timedout, internal_err, err2, err3....}).

And in the erlang code (and external database inserts  wherever applicable),
I just use the positional value of the enum,
i.e. #myerrors.ok     or    #myerrors.internal_err and so on.

This way I get code readability, external db representation as well as
grouping of like entities.

The enums of course end up starting from the number 2, but then I don't
really care for the value.


On Tue, Aug 18, 2009 at 1:59 PM, Dave Pawson <dave.pawson@REDACTED> wrote:

> Hi Steve.
> 2009/8/18 Steve Davis <steven.charles.davis@REDACTED>:
> > Dave,
> > Here's my 2c on this one.
> >
> > 1) reuse atoms that are also used as return values from other modules
> > in the OTP platform where it makes sense,
> Makes sense. I'm using ok etc as I've seen it used.
> > 2) try to name the atoms cleverly for best grok-ability
> :-) OK. by the reader I guess.
> > 3) if you return an unpredictable number of status values, then use
> > "string" status values
> See below*
> > 3a) and... by "string" then probably it is "better" to use a binary
> > representation of the text, e.g. <<"my unpredictable return value">>
> Never even seen that way of building a string!
> My problem is a function that should return, say, a record, yet
> the sought record does not exist?
>  Return a 'dummy' / null record or
>  Just a status value?
> Groking in the case would be by the Erlang code rather
> than the user.
> suggestions on how to handle this please?
> regards
> --
> Dave Pawson
> Docbook FAQ.
> http://www.dpawson.co.uk
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org

More information about the erlang-questions mailing list