www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Associative array mutation of a value

reply "bearophile" <bearophileHUGS lycos.com> writes:
Recently Erlang language has added several things:
http://joearms.github.io/2014/02/01/big-changes-to-erlang.html

One interesting change is the syntax to handle associative arrays 
(that are meant to be used a little like records):

 Updating a map is done as follows:
 
 NewX = X#{ key1 => Val1, ... KeyN := ValN, ...}

X is the old associative array. "=>" adds a mew key, while ":=" updates an already existing key, and if it's not present an error is generated. So a spelling mistake cannot accidentally introduce a new key if you want to update some value. This avoids a common mistake. I am not suggesting to add a new syntax to D, but perhaps a simple "AA.update(key, val)" function in the object module can be useful. Bye, bearophile
Feb 06 2014
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 6 February 2014 at 14:15:47 UTC, bearophile wrote:
 Recently Erlang language has added several things:
 http://joearms.github.io/2014/02/01/big-changes-to-erlang.html

 One interesting change is the syntax to handle associative 
 arrays (that are meant to be used a little like records):

 Updating a map is done as follows:
 
 NewX = X#{ key1 => Val1, ... KeyN := ValN, ...}

X is the old associative array. "=>" adds a mew key, while ":=" updates an already existing key, and if it's not present an error is generated. So a spelling mistake cannot accidentally introduce a new key if you want to update some value. This avoids a common mistake. I am not suggesting to add a new syntax to D, but perhaps a simple "AA.update(key, val)" function in the object module can be useful. Bye, bearophile

AA[key] = val; ?
Feb 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Tobias Pankrath:

 AA[key] = val; ?

I don't understand. That syntax doesn't give you an error if 'key' is missing in AA. Bye, bearophile
Feb 06 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 6 February 2014 at 15:16:14 UTC, bearophile wrote:
 Tobias Pankrath:

 AA[key] = val; ?

I don't understand. That syntax doesn't give you an error if 'key' is missing in AA. Bye, bearophile

yes, brainfart. For a moment I thought that the index would throw if key is missing, return a reference otherwise and assign val to it. That's obviously wrong.
Feb 06 2014
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 6 February 2014 at 14:15:47 UTC, bearophile wrote:
 Recently Erlang language has added several things:
 http://joearms.github.io/2014/02/01/big-changes-to-erlang.html

 One interesting change is the syntax to handle associative 
 arrays (that are meant to be used a little like records):

 Updating a map is done as follows:
 
 NewX = X#{ key1 => Val1, ... KeyN := ValN, ...}

X is the old associative array. "=>" adds a mew key, while ":=" updates an already existing key, and if it's not present an error is generated. So a spelling mistake cannot accidentally introduce a new key if you want to update some value. This avoids a common mistake. I am not suggesting to add a new syntax to D, but perhaps a simple "AA.update(key, val)" function in the object module can be useful. Bye, bearophile

I'm always for little helper functions, but I don't think Erlang's idiom of using maps as records is good for D. That model works well with dynamic typing, where record types are meaningless and only their structure is important(JavaScript is fine example). With static typing it's better to declare a type for the record, so whether the field you are trying to set exists or not can be checked at compile-time. Besides, the usefulness of maps-as-records will be quite limited in D, since associative arrays has a fixed value type. To store different types in different fields, we'll need to stringly-type them(very bad!), use pointers abd casting(not that bad but still bad!) or use Variant - which is better than the first two solutions but still not as good as simply using structs or classes.
Feb 07 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Idan Arye:

 but I don't think Erlang's idiom of using maps as records is 
 good for D.

I didn't meant to use that idiom in D, and I am not suggesting its usage in D. I wanted just to suggest an alternative way to modify associative array values that requires the keys to be already present. Because this is a common operation where you don't want to add a new key by mistake. Bye, bearophile
Feb 07 2014
prev sibling parent "renoX" <renozyx gmail.com> writes:
On Friday, 7 February 2014 at 20:22:54 UTC, Idan Arye wrote:
 I'm always for little helper functions, but I don't think 
 Erlang's idiom of using maps as records is good for D. That 
 model works well with dynamic typing, where record types are 
 meaningless and only their structure is important(JavaScript is 
 fine example). With static typing it's better to declare a type 
 for the record, so whether the field you are trying to set 
 exists or not can be checked at compile-time.

The thing is, you don't always have those key at compile time.. Anyway, the discussion here is about map not record and IMHO it is a good idea to have two short functions for 'replace an existing value' and 'add a new key' then a long one for 'do both' because users tend to use short names and from a maintainability point of view, it's much better to know what was the exact intended meaning of the one who wrote the code, instead of having to guess, he wrote "array[key] = value" did he want to add the key or did to replace an existing key? BR, renoX
Feb 10 2014