Structs (was RE: Record selectors)

[Sean Hinde]

>   With structs you can write things like:
> 
> 	A = ~{name="joe", footSize=42},   %% define a struct
> 	A.footSize,                       %% access a field
> 	B = ~A{likes="motorbikes"},       %% add a new field
> 	~{likes=X, name=N} = B}           %% pattern match etc.
> 
>   *without* any record defs.
> 
>   Everything  is dynamic  (which gives  it a  nice Erlang  flavor) and
> things are consistent between different modules - so no .hrl files are
> needed. Efficiency  would be *jolly  good* (TM) if implemented  in the
> VM.

We have been thinking about the strengths and weaknesses of structs and how
we might have written some of our recent systems using them.

A number of our recent systems seem to follow a pattern of:

 - Decode input data into some tagged tuple format (e.g. HTTP Header,
Billing Record)
 - Convert this into a record for lots of nice random access and processing.
 - Make a tagged tuple list from the relevant parts of the record.
 - Send this to another process
 - Other process converts it into a record of a new type for random access
 - Other process makes some wierd output packet structure using named record
fields.

I guess this is driven by the need for nice named random access for the
processing parts of the application but flexible and extensible tagged tuple
lists for communicating between different parts of the app - no need for
global .hrl files amd the headaches they bring.

For this application structs would appear to be a magic bullet - they are
extensible and also random access. Some concerns would be:

a) A typo in the name of a single field would be a fairly hard to find bug -
unwittingly creating a new field rather than just updating an existing one
would be hard to see.

b) The absense of default values would make explicit initialisation of many
structs mandatory - lots more typing for little gain and potential for more
unchecked and hard to find field naming errors.

c) It would be very easy to make fairly unreadable code where the same
struct name was used many times in the same module to refer to totally
different structs.

d) We concluded we probably wouldn't use anonymous structs over simple
tagged tuples - the possibility for error in field naming and the potential
confusion from using the same field names for different instances of a
struct (which one is this one again ??) probably outweigh the advantages.

One nice benefit would be that it would be very easy to check that input
data had the correct number of entries - at the moment validating that the
following type of code has filled in all entries in the record needs an
extra longwinded trawl through all fields:

parse(Vals) ->
	parse(Vals, #person{}).

parse([{name, Name}|T], Rec) ->
	parse(T, Rec#person{name = Name});
parse([{job, Job}|T], Rec) ->
	parse(T, Rec#person{job = Job});
parse([], Rec) ->
	Rec.

with structs it would be sufficient to check the number of fields created.

I think that named structs with the addition of optional static definitions
would be an excellent addition to Erlang. (The definitions would have no
effect at runtime but would provide a very useful crutch for those of us
with weak typing skills.) 

I would also still like to see xref style support for checking cross module
record definitions - and why not global struct definitions as well..

Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030114/b5564cf1/attachment.htm>