Contribution to the record- and write-your-own-guards debates

[Anders Ramsell]

Fredrik Linder wrote:
> 
> I so would have loved to see that field value restrictions was a part of the
> record declaration. But then again, records are tuples (I know, but I guess
> that's how most of us view them), and hence "not possible".
> 
> What I really would like to see is a new kind of data container, similiar to
> records, with at least the following properties:
> 
>  o Named fields (atom names only)
>  o Field value restriction (to be checked at assignment in run-time)
>  o Non-destructable (as with all other types)
>  o Generic field accessors (to be used as guards)
>  o No default values (don't mix declaration with definition)
>  o Un-ordered fields (field order is of absolutely no interest)
> 

There is one thing I have been missing in the ongoing debate of 
replacing/complementing records with a new and "better" construct. This 
may be because most people find it too obvious to mention. I think it's 
worth mentioning.

To me what makes records great (I think they are) is that they can be 
inserted into ETS and DETS tables. Without this functionality records 
would only be useful. If "structs" or whatever they may be called would 
have to be wrapped in records before inserting them into an ETS table 
and then unwrapped again after extraction that would make coding a lot 
more tiresome. If that where the case I think I would continue using 
records instead.

In conclusion I would like to add the following to the list of required 
properties for "structs":

- Builtin support in ETS and DETS

/Anders