[erlang-questions] Maps

Loïc Hoguin essen@REDACTED
Tue May 14 22:38:43 CEST 2013

On 05/14/2013 09:05 PM, Jachym Holecek wrote:
> # Lo?c Hoguin 2013-05-14:
>> On 05/14/2013 03:07 PM, Robert Virding wrote:
>>> Lo?c you and I can meet at dawn like gentlemen to discuss special syntax
>>> or not. Swords or pistols? :-)
>> Pistols.
>> I don't disagree with most of what you say. The special syntax isn't
>> really needed until you get a project where you need to keep really many
>> things in the state (hundreds if not thousands of terms per connection)
>> and update them many times, in my case many times per second, while
>> still striving for low latency.
> Have you considered ETS tables? A private ordered_set variety would seem
> to fit your needs rather well, based on what you just said and an example
> you gave in an earlier post. You mention keeping large state, be mindful
> this may, inherently, be playing against your low latency goal if you keep
> all the data on heap. Well, depending on what precisely you mean by "large
> state" and "low latency".
> Just briefly -- you mentioned you need to maintain nested objects along
> with attributes:
>    true = ets:insert_new(Tid, {{Player_id, possesions, Item_id, count}, 1})
> There's also ets:{update_counter/X|lookup_element/X}, and ets:select/X with
> known prefix behaves just nice too. Maybe a list would work better as key
> type than tuple. Anyway, you get the idea.

Thanks but I already know ets. ets is too verbose, and I can't pattern 
match against values easily in function clauses.

There's been a thread a while back with various "solutions" being given, 
none coming close to what maps can allow, most particularly none 
allowing matching in function clauses, which is the other requirement 
for the code to be tidy.

> Also -- you could consider using processes to encapsulate various bits of
> state.

I'd just be passing the data back to the connection process all the 
time, it's pointless. I don't control the protocol, and the protocol 
requires many superfluous values to be sent to the client all the time. 
The only thing I can control is how I structure things to make this 
easier for me, and avoid writing too much code to do it. Maps allow me 
to do that.

>> How do you access deep values in JSON in Erlang?
> I don't. Usually it ends up being pretty reasonable to convert them to
> Erlang-friendly internal representations on protocol boundaries (good
> thing one mostly knows what parts of them are actually of intereset),
> these end up being mostly flat -- often tagged-value lists or records.
> For conversion itself -- layer-by-layer, accumulating the result as
> you go. But clearly, it all depends on the details here.

If you only had objects you could do it in a single line with maps. If 
you also have arrays, it'll be one list comprehension per array on top 
of that, with possible operations inside it. You could process your 
whole JSON with a one liner. No accumulators, not lists:reverse, no need 
to write any function, and most likely a lot more optimized with less 
chances of bugs than you'd have done otherwise.

>> How do you update a value in JSON? How do you update 20 of them?
>> Painfully.
> Convert them to something sensible and only then process them? A few
> utility functions on top of tagged-value lists can work miracles for
> you, for example.

I know what I can do today, you don't need to tell me. I also know what 
I could do tomorrow. The future looks pretty damn good.

Loïc Hoguin
Erlang Cowboy
Nine Nines

More information about the erlang-questions mailing list