> 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.
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?
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.
Jesse
· 1 year ago
Gleb,
Good catch. And thanks for pointing to proplists, I didn't know about them.
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.
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,
vladev
· 3 weeks ago
Hi, great post.
You have a slight mistake thought:
"Since Erlang is side-effect free state cannot be kept globally." What I think you meant was that Erlang is a functional language. Functional languages don't have state. Imperative do.
Erlang is not side-effect free language. Printing to the console is not a side-effect free operation and you can do it from virtually everywhere in Erlang. A side effect free language would be useless - you won't be able to communicate with anything (terminal, socket, etc.). Haskell can be thought of being a side-effect free, where side effects are controller by monads.
All Comments
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}.
> 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.
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.
Good catch. And thanks for pointing to proplists, I didn't know about them.
You have a slight mistake thought:
"Since Erlang is side-effect free state cannot be kept globally."
What I think you meant was that Erlang is a functional language. Functional languages don't have state. Imperative do.
Erlang is not side-effect free language. Printing to the console is not a side-effect free operation and you can do it from virtually everywhere in Erlang. A side effect free language would be useless - you won't be able to communicate with anything (terminal, socket, etc.). Haskell can be thought of being a side-effect free, where side effects are controller by monads.
Regards