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

[Amit Murthy]

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.

  Amit


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
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>