[erlang-questions] Best Practice in Map keys: Atoms or Binaries (or Strings)?

[Vans S]

That is bad design and advice IMO.  Structs in elixir define object orientation, functional programming is about data, everything is data.  The tuple being a core building block.

When you define your application using structures, you have just added an extra layer of inference.  Now in most cases that extra layer will just get in your way, providing no reasonable benefit.

One of the biggest enlightenments and problems Erlang developers learn early on is the record.  First the record is pretty much a Struct in Elixir, with some insignificant differences.  Now most developers would do this;  define rigid records like 'User', 'Location', 'Job' with default values and  start writing expressions to work with them.  Before the developer knows it, the record is being used throughout multiple modules across the entire code base. Everything is unit tested and static analysis reports the code is 100% excellent, not a single flaw.

Now the developers code is running in production and its working great! 

But now a problem comes along, the job the code does has changed, storing the email_verification_token inside the 'User' record is no longer valid, and a new record is created called 'Validation' that houses email_verification_token with sms tokens and other validations.  Sure no problem, well defined structure is awesome!

The entire code base was written rigidly following the spec defined by the records (Struct), as soon as we want to make a change now multiple modules need to be rewritten.  Now this is not a problem, a day can be expent to rewrite/replace 20 modules that use that record. Done, rewritten!  

Now the developers code is running in production and its failing :(

Turns out by simply replacing text in 20 modules something was missed that is producing undefined behavior now. The project is rolled back in production to the previous version and the entire development process starts all over, trying to figure out where the bug is that was introduced from the simple record change.


Tl; Dr:  Never rely on records (Elixir Structs) across multiple modules, always write expressions that manipulate DATA, never write expressions that manipulate OBJECTS (oop definition).


On the count of maps anything used as a key is optimal, there is no limitations. Maps are a great flexibility and there is no one right way to use them. An example of a useful map key:

DataChannelLookup#{}
maps:put({peer1, peer2}, Channel, DataChannelLookup)
maps:put({peer2, peer1}, Channel, DataChannelLookup)
maps:put({peer2, peer3}, Channel2, DataChannelLookup)
maps:put({peer3, peer2}, Channel2, DataChannelLookup)

Channel2 = maps:get({peer2, peer3}, DataChannelLookup)


 

    On Saturday, October 1, 2016 7:52 AM, Uniaika <uniaika@REDACTED> wrote:
 

 Maybe this blog post (originally for Elixir though) will help you:
https://engineering.appcues.com/2016/02/02/too-many-dicts.html

TL;DR

>    WUse string-keyed maps for data which has just arrived from an >
external source.

>    Convert external data to structs as soon as possible.

>    Use structs almost everywhere else in your program.

>    Use other atom-keyed maps sparingly.

On 10/01/2016 12:37 PM, Pagayon, Ruel wrote:
> Hi everyone,
> 
> I'm just wondering (assuming the keys of my maps in my application is
> not dynamically generated):
> 
> 1. What is the most optimal key type for maps?
> 2. If there is little to no effect in performance (or resources in
> general), as a convention, which is the best to use?
> 
> Thank you in advance for your responses.
> 
> Cheers,
> Ruel
> 
> 
> _______________________________________________
> 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/20161001/091ce166/attachment.htm>