<div dir="ltr">On Wed, May 24, 2017 at 4:31 PM Son Tran-Nguyen <<a href="mailto:son@sntran.com">son@sntran.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">If any, please consider letting the develop to choose whether they want to convert the binary to atom. If the library switch itself to using atoms, then the developer cannot really do anything about it.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff"><br></div></div></blockquote><br></div><div class="gmail_quote">If we make the switch, I'm pretty sure the developers won't be given a choice. The complexity of managing this will essentially mean every module in the system needs lots of small fixups. The cost/benefit analysis doesn't pan out.<br><br></div><div class="gmail_quote">The impedance mismatch is when you have a field as an atom, 'created' for instance. But your object stores it as <<"created">> in a map or proplist. In this case, the code would change from<br><br></div><div class="gmail_quote">execute(_, Obj, Field, _) -> {ok, maps:get(Field, Obj, null)}<br><br></div><div class="gmail_quote">to<br><br></div><div class="gmail_quote">execute(_, Obj, Field, _) -> {ok, maps:get(atom_to_binary(Field, utf8), Obj, null)}<br><br></div><div class="gmail_quote">which I don't think is a problem in the long run. It would help if the data is a #record{} type on the other hand.<br><br></div></div>