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

T Ty tty.erlang@REDACTED
Sun Jun 2 20:33:32 CEST 2019


I recommend using record for a very different reason and not in the form
you showed in your example.

My recommendation is to prefix the module name to the record. e.g

```
-module(ppool_serv).

-record(ppool_serv_state, ...).
```

My reasoning is during an error report having just a list or tuple or map
would result in an unintelligible data structure displayed. With a record,
as above, you can determine at a quick glance the record in question. It is
also easier to determine the attributes in the record in this manner.

Cheers



On Sun, Jun 2, 2019 at 2:24 PM I Gusti Ngurah Oka Prinarjaya <
okaprinarjaya@REDACTED> wrote:

> 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
>>
>>
>> _______________________________________________
> 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/9283ec70/attachment.htm>


More information about the erlang-questions mailing list