atoms used as status info, 'constants' etc

[Steve Davis]

A tip on records -- as I learned recently (on this list no less), the
most efficient way of filtering returned records would be e.g...

case Value of
#my_rec_a{} -> ...;
#my_rec_b{} -> ...;
_ -> {error, {invalid_type, Value}}
end

This is far more efficient that using an is_record() guard

/sd

On Aug 18, 3:29 am, Dave Pawson <dave.paw...@REDACTED> wrote:
> Hi Steve.
>
> 2009/8/18 Steve Davis <steven.charles.da...@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. Seehttp://www.erlang.org/faq.html
> erlang-questions (at) erlang.org