The record in Erlang.

There are only two mixed data types within Erlang: list and tuple, neither of which supports named access, so it is not possible to create associative arrays (hash in ruby) in PHP, Ruby, or Python if there is no additional library.
In Ruby I can do this:

1. server_opts = {:p ort + 8080: ip = ' 127.0.0.1 ',: Max_connections = Ten}

This expression is not supported at the grammar level of Erlang

To avoid this limitation, the Erlang virtual machine provides a pseudo-data type called a record
The record supports named Access, and later we'll see why we call it "pseudo" data types

Defining a record
The record is more like a struct in C than an associative array, which must be defined at the outset and can only hold data.
Here is a record example of the connection option for a server:

1. -module (My_Server).
3. -record (Server_opts,
4. {port,
5. ip="127.0.0.1",
6. max_connections=10}).
8. % the rest of your code goes here.

The record is declared with the-record directive, the first parameter is the name of the record, and the second parameter is a tuple,tuple that contains the field and default values in the record.
Here we define the server_opts record, which has three field: Port, IP, and maximum number of connections
There is no default Port,ip default value of "127.0.0.1", max_connections default value is 10

Create record
The record is created by using the # symbol, which is the legal way to create an instance of the Server_opts record:

1. Opts1 = #server_opts {port=80}.

This code creates a server_opts Record,port set to 80, and the other field uses the default value

1. Opts2 = #server_opts {port=, ip="192.168.0.1"}.

This code creates a server_opts Record, but the IP is set to "192.168.0.1"

In short, when creating a record, you can include any field, and the omitted field will use the default value

Access Record
The record was accessed in a clumsy way, and if I wanted to access the Port field, I could do this:

1. Opts = #server_opts {port=, ip="192.168.0.1"},
2. Opts#server_opts.port

Every time you want to access a record, you have to include the name of the record.
Because the record is not really an internal data type, it is just a trick of the compiler.

Internally, the record is a tuple, as follows:

1. {server_opts, "127.0.0.1", ten}

The compiler maps the name of the record into a tuple
The Erlang virtual machine records the definition of the record, and the compiler translates all the record logic into a tuple logic
Therefore, there is no record type at all, so every time you visit a record you have to tell Erlang which record we are using (for the compiler to cool, the programmer gets very upset)

Update Record
Updating the record is similar to creating a record:

1. Opts = #server_opts {port=, ip="192.168.0.1"},
2. newopts = opts#server_opts{port=7000}.

Here first create a server_opts Record
Newopts = opts#{port=7000} Creates a copy of the Opts and specifies that port is 7000 and bound to newopts

match record and guard statements
Don't talk about pattern matching, it's not Erlang.
Let's take a look at an example:

1. Handle (opts= #server_opts {port=8000})
2. % do special port 8080 stuff
3. Handle (opts= #server_opts {}
4. % Default Stuff

The guard statement is similar to the above, for example, a port with a binding of less than 1024 usually requires root privileges, so we can do this:

1. Handle (Opts) when Opts#server_opts.port <=
2. % requires root access
3. Handle (opts= #server_opts {})
4. % doesn ' t require root access

Use record
In my limited time using Erlang, I found that the record was mainly used in two scenarios
First, the record is used to save the state, especially when using Gen_server's behaviour
Since Erlang cannot hold state globally, the State must be transmitted before the method
The record can then be used to save the configuration options, which can be considered a subset of the 1th
Nonetheless, the record has some limitations, most notably the inability to add and remove field at run time, which, like C's struct, must be pre-defined in the structure of the record
If you want to add and remove field at run time, or if you are running to determine which field, you should use dict instead of record

The record in Erlang.