<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Feb 29, 2016 at 6:21 AM Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks all for the answers it's useful !<br><br><div class="gmail_quote"></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 5:56 PM Garrett Smith <<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 10:23 AM Benoit Chesneau </div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>So would you se a maps instead of a record when you need to share the returned result with apps that depends on your library? Instead of making that result opaque and provide functions to access it? Which sound ridiculous sometimes, since at the end what you do is a get on a record key ... Curious what others do in that case?</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>What's the nature of the data? If it's a map of keys to values, I think map is a good data type. E.g. I think a database row is well represented as a map, as columns/fields tend to differ based on what you're retrieving.<br></div><div><br></div><div>Maybe a good test is the one you mentioned - if you're module is simply providing a bunch of pass-throughs to peel off record fields, it wants to be a map.</div></div></div></div></blockquote><div><br></div><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I was thinking to this simple example:</div><div><br></div><div>I have a function hackney_url:parse_url() returning a record #hackney_url{} . This record can be used internally but also externally by the applications that need it. Which requires for now to include "hackney_lib.hrl" . The record will likely change. On the other hands I am not sure I like to have to import the include file to get its definition (or copy this definition in another file, or just use the tuple) .</div></div></div></blockquote><div><br></div><div>At least historically the canonical form here is to use a record and provide the definition in a public facing include. I'm thinking of file:read_info as an example.</div><div><br></div><div>I think it's less obvious to use maps.</div><div><br></div><div>I'm starting to use maps for process state just to see how it feels - it's not a major break through for me. I miss the very rudimentary type safety - it feels a bit odd to structure typed values as maps.</div><div><br></div><div>I poked around corresponding Python interfaces to see what they're using and of course typey values like parsed URLs are typically objects. Using dicts would again be odd there.</div><div><br></div><div>I say keep it old school!</div></div></div>