7 comments

• 

  Gleb Peregud

  1 year ago

  In the "Updating Records" there is one issue.
  
  Opts = #server_opts{port=80, ip="192.168.0.1"},
  NewOpts = Opts#{port=7000}.
  
  should look like this:
  
  Opts = #server_opts{port=80, ip="192.168.0.1"},
  NewOpts = Opts#server_opts{port=7000}.
  reply
• 

  Gleb Peregud

  1 year ago

  Sorry for double posting.
  
  > Perhaps a subset of the first, records are also used to keep track of configurable options.
  
  Yes, records may be used for this. But sometimes proplists are better choice, take a look at http://www.erlang.org/doc/man/proplists.html:
  
  > Property lists are useful for representing inherited properties, such as
  > options passed to a function where a user may specify options overriding
  > the default settings, object properties, annotations, etc.
  reply
• 

  website design

  1 year ago

  > so creating associative arrays a la PHP, Ruby, or Python is an impossibility. ... some more bloggery ... > If you want to to add and remove fields on the fly, or if you don't know what fields you'll have until runtime, you should use [dicts](http://www.erlang.org/doc/man/dict.html) rather than records. Huh?
  reply
• 

  Jesse

  1 year ago

  website,
  
  I'm not sure if you're a real person or a spam bot, but by "a la PHP, Ruby, or Python" I meant as a first-order construct. I'll reword it so it's less ambiguous.
  reply
• 

  Jesse

  1 year ago

  Gleb,
  
  Good catch. And thanks for pointing to proplists, I didn't know about them.
  reply
• 

  Robert Virding

  1 year ago

  Records were never intended to be anything else other than providing named fields for tuples. In this respect they *are* like C structs and should not be confused with associative arrays, use dict, orddict or gb_trees for that. Or ETS.
  reply
• 

  Alain O'Dea

  1 year ago

  Good article. Thank you for the concise and clear description of Erlang's records mechanism. It answered a few questions I had about guards,
  reply