[erlang-questions] Maps

[Jachym Holecek]

# 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.

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

> When you have that many values, your first enemy is verbosity, not only 
> to be able to write the code fast, but also to find the bugs in it 
> quicker. Execution speed only comes after. Of course by verbosity I 
> don't mean saving a character or two, I mean that what the code says is 
> simpler.

True. It may be that a native type would help, it may be that more careful
choice of data representation and analysis of data flows in your application
would help a lot more (not to come across patronizing here -- I'm reminded
of a few messy protocol converters/gateways we did at ${dayjob}).

> For example, why would you want to say "I want to extract this 
> value V1 then extract this value V2 then modify a value in V2 then put 
> V2 back in V1 then put V1 in the original structure" instead of "I want 
> to modify this deep value there"? We shouldn't have to worry about all 
> these intermediate operations. They're a lot longer to write, and a 
> bigger source of error.
> 
> My personal use case is probably not that universal, but I believe it 
> also applies to anyone who has to access or modify JSON or equivalent 
> (not XML).

<rant>The exact degree of ugliness and dismal design work in all these
"modern" HTTP-ish "protocols" is perhaps new</rant>, dealing with deeply
nested data structures on external interfaces is not...

> 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.

> 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.

> You can write functions to do it if you don't need to do it many times
> in your program, but the more you need to do it the more you'll want a
> special syntax to actually get things done instead of handling the
> details of the modification.

Just to be clear: I'm not expressing any opinions about any existing or
fictitious EEP. Merely trying to approach your problem from a different
angle, a more general one I think. Also my suggestion to use ETS in not
necessarily related to following points about data representation.

BR,
	-- Jachym