[erlang-questions] Why use -record() ?

[I Gusti Ngurah Oka Prinarjaya]

Hi,

Thank you for all of you guys. It's very very clear now. Wow.. very
enlightening! thank you.

The key is:
Using tuple will ruin your life when you need to add a new element in your
state. Because tuple do really really need to match the order of elements.
Because yes i absolutely  lazy to remember the order of tuple's elements.

Thank you for the additional knowledge about type theory algebra data
types, it's a new knowledge for me.




Pada tanggal Min, 2 Jun 2019 pukul 18.57 Dmitry Kolesnikov <
dmkolesnikov@REDACTED> menulis:

> Hello,
>
> There was quite good reasoning already about records. I just want to make
> a quotation from my resent post about records. I hope it helps you to catch
> the reason why…
>
> Type theory and a functional programming operates with [algebraic data
> types](https://en.wikipedia.org/wiki/Algebraic_data_type). They are known
> as a composition of other types. The theory defines two classes of
> compositions: product types (tuples, records) and co-product types (sum,
> enumeration or variant types). Product types are strongly expressed by
> [records](http://erlang.org/doc/reference_manual/records.html) in Erlang.
>
> ```erlang
> -type fullname() :: binary().
> -type address()  :: binary().
> -type city()     :: binary().
>
> -record(person, {
>    name    :: fullname(),
>    address :: address(),
>    city    :: city()
> }).
> ```
>
> The beauty of Erlang records (product type) is that they definitions are
> only available at compile time. The compiler has complete knowledge of
> defined "algebra" and catches misuse errors. The usage of records in your
> code benefits to write correct, maintainable code and support refactoring.
> Use them to define your domain models!
>
> ```erlang
> #person{birthday = "18810509"}.
>
> %% Compiling src/person.erl failed
> %% src/person.erl:18: field birthday undefined in record person
> ```
>
> There are few other benefits of records over other data types: type
> testing and pattern matching. These subject has been widely covered at
> [official documentation](
> http://erlang.org/doc/programming_examples/records.html):
>
> ```erlang
> %%
> %% type testing
> myfun(X) when is_record(X, person) -> ...
>
> %%
> %% pattern matching
> myfun(#person{name = Name}) -> ...
> ```
>
> As a summary, I would strongly advertise the usage of records to reflect
> your domain. Other types will work too...
>
> Best Regards,
> Dmitry
>
> On 2 Jun 2019, at 14.34, bengt <cean.ebengt@REDACTED> wrote:
>
> Greetings,
>
> It is true that it is a matter of taste but remember that some Erlang
> containers can not be used to pattern match. Using one of those
> handle_call/3 would only be one function clause. And while maps can be
> pattern matched the compiler will not help you with spelling mistakes, as
> it does with records.
>
>
> Best Wishes,
> bengt
>
> On 2 Jun 2019, at 13:25, Stefan Hellkvist <hellkvist@REDACTED> wrote:
>
>
> ...
> handle_call({run, Args}, _From, {Limit, Spv, Refs, Queue}) when N > 0 ->
>   {ok, Pid} = supervisor:start_child(Spv, Args),
>   Ref = erlang:monitor(process, Pid),
>   NewRefs = gb_sets:add(Ref, Refs),
>   NewState = {Limit-1, Spv, NewRefs, Queue},
>   {reply, {ok, Pid}, NewState};
>
> We also can use the above alternative code right?
>
>
> Yes, you can use whatever Erlang term you prefer - record, tuple, map, a
> list of maps containing records of tuples...
>
> What you choose is a matter of taste and depends on your requirements. A
> record for instance has the advantage over a tuple, that you access
> elements by name and the order of elements therefore becomes irrelevant.
> This could give advantages if you one day decide to add another field to
> your state. With the tuple approach this would likely break every access to
> the tuple everywhere in the code, but with a record where you access and
> match by names most of your code might still work...plus you never need to
> remember what meaning the third or fourth element in your tuple has l,
> because it has a descriptive name.
>
> Stefan
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> 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/20190602/f4573a7a/attachment.htm>