<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hello,</div><div class=""><br class=""></div><div class="">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…</div><div class=""><br class=""></div><div class=""><div class="">Type theory and a functional programming operates with [algebraic data types](<a href="https://en.wikipedia.org/wiki/Algebraic_data_type" class="">https://en.wikipedia.org/wiki/Algebraic_data_type</a>). 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](<a href="http://erlang.org/doc/reference_manual/records.html" class="">http://erlang.org/doc/reference_manual/records.html</a>) in Erlang. </div><div class=""><br class=""></div><div class="">```erlang</div><div class="">-type fullname() :: binary().</div><div class="">-type address() :: binary().</div><div class="">-type city() :: binary().</div><div class=""><br class=""></div><div class="">-record(person, {</div><div class=""> name :: fullname(),</div><div class=""> address :: address(), </div><div class=""> city :: city()</div><div class="">}).</div><div class="">```</div><div class=""><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class="">```erlang</div><div class="">#person{birthday = "18810509"}.</div><div class=""><br class=""></div><div class="">%% Compiling src/person.erl failed</div><div class="">%% src/person.erl:18: field birthday undefined in record person</div><div class="">```</div><div class=""><br class=""></div><div class="">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](<a href="http://erlang.org/doc/programming_examples/records.html" class="">http://erlang.org/doc/programming_examples/records.html</a>):</div><div class=""><br class=""></div><div class="">```erlang</div><div class="">%%</div><div class="">%% type testing</div><div class="">myfun(X) when is_record(X, person) -> ...</div><div class=""><br class=""></div><div class="">%%</div><div class="">%% pattern matching</div><div class="">myfun(#person{name = Name}) -> ...</div><div class="">``` </div></div><div class=""><br class=""></div><div class="">As a summary, I would strongly advertise the usage of records to reflect your domain. Other types will work too...</div><div class=""><br class=""></div>Best Regards,<div class="">Dmitry<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Jun 2019, at 14.34, bengt <<a href="mailto:cean.ebengt@gmail.com" class="">cean.ebengt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Greetings,<br class=""><br class="">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.<br class=""><br class=""><br class="">Best Wishes,<br class="">bengt<br class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 2 Jun 2019, at 13:25, Stefan Hellkvist <<a href="mailto:hellkvist@gmail.com" class="">hellkvist@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><font face="courier new, monospace" class="">...<br class="">handle_call({run, Args}, _From, {Limit, Spv, Refs, Queue}) when N > 0 -><br class=""> {ok, Pid} = supervisor:start_child(Spv, Args),<br class=""> Ref = erlang:monitor(process, Pid),<br class=""> NewRefs = gb_sets:add(Ref, Refs),<br class=""> NewState = {Limit-1, Spv, NewRefs, Queue},<br class=""> {reply, {ok, Pid}, NewState};</font><br class=""></div><div class=""><br class=""></div><div class="">We also can use the above alternative code right?<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, you can use whatever Erlang term you prefer - record, tuple, map, a list of maps containing records of tuples...</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Stefan </div></div>_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class=""><a href="http://erlang.org/mailman/listinfo/erlang-questions" class="">http://erlang.org/mailman/listinfo/erlang-questions</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class="">http://erlang.org/mailman/listinfo/erlang-questions<br class=""></div></blockquote></div><br class=""></div></body></html>