Alternatives to records

[Ulf Wiger]

Personally, I tend to use {Key,Value} lists more and more as an
alternative to records, especially when I want to handle a variety of
options in an API function - as this is often the case for me, I tend
to carry the options list with me, and use expressions like:

X = get_opt(Key, Options, DefaultValue)

Personally, I'd prefer it if I could have a hash object on the process
heap. Then, I wouldn't have to worry about the cost of doing lots of
linear searches in my code.

I have no good idea of how such a hash object should be represented
syntactically. I've not seen any new exciting symbols pop up on my
keyboard lately... 

Perhaps simply through a set of functions (after all, Erlang is a
functional language)?

set(Options)				-> Set (HashObject)
list_to_set([tuple()], SetOptions)	-> Set
lookup_in_set(Set, Key) 		-> tuple()
insert_in_set(Set, tuple())		-> NewSet
delete_from_set(Set, Key)		-> NewSet

Of course, any of the Erlang-based access structures have this type of
semantics, so there may not be a need for anything new - except
perhaps that these access structures are often hard to read when you
look at a crash report or a trace message. A set() datatype could be
nicely formatted in a manner similar to a list by the runtime system.


/Uffe

On Wed, 6 Dec 2000, Peter Andersson wrote:

>
>Hi,
>
>I'm looking for a data representation to use as an alternative to Erlang records
>in a particular application of mine. I want the possibility to reference data
>elements by means of labels rather than positions.  
>
>The reason for not using records in the first place is that, in this case, I
>want the possibility to retrieve the data dynamically, like "get_value(Key,
>Record)", which is impossible with records (since the names must be hardcoded).
>I would prefer to handle the data in a "side-effect-free" fashion, i.e. not use
>explicit tables for storage, but pass the values around as arguments. The
>structures will never contain many or large elements but there will be *many* of
>the structures being created on multiple processes during the lifetime of the
>application and they will be accessed frequently. Insert/lookup must be
>efficient!
>
>I'm thinking a simple list of key-value tuples ([{key1,Val1},...]) would be the
>best choice, since the lists should never be really big (the simplest anyway,
>with already existing support by the lists:key* functions). I thought I'd post
>this question to the list, though. (I'm often surprised how much there is to
>learn from the discussions here - the detailed ones as well as the more general
>ones!). Are there any other alternative representations worth considering? Or
>are there perhaps ways to reference Erlang record elements dynamically that I
>haven't thought of or found out about (not using the tuple representation, that
>is)?
>
>Regards
>
>  /Peter
>

-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB