> X-url: http://www.bluetail.com/~rv > To: Hakan Stenholm <etxhste>
> cc: erlang-questions
> Subject: Re: records
> MIME-Version: 1.0
> Content-ID: <1428.1007466407.1>
> Date: Tue, 04 Dec 2001 12:46:52 +0100
> From: Robert Virding <rv>
> Hakan Stenholm <etxhste> writes:
> >The imidiat problem can be solved by adding a guard
> >"foo(A, ...) when record(A, ...) ->" to do the type checking.
> > .......
> This is, of course, all true, BUT in the documentation records are
> defined to be tuples so it really shouldn't come as a surprise. The
> reason for this is that when records were first implemented it wasn't
> possible at that time to easily add a new datatype in the
> implementation. This has changed today.
> Seriously, how many people/apps would be severely burned if records
> *were* made their own datatype? It is possible to do but you have to
> determine which solution hurts the most.
Actualy I'm quite aware of this, there is a lot of code that relies on records
being tuples: lists:keysearch, ets tables, code change code in the AXD301 ...
so I can't say that I expect the implementation to change.
But I suppouse it would still be posible to change the tuple representation to
something else, for example:
i.e. add an extra '__record' type indicator in the tuple, '__record' should then
be a reserved key world, that should not be allowed to be used in regular code -
which stops the user from acidently putting it in tuples.
Or we might handle all tuples that start with a record name (thats defined in
any loaded file) as a record (i.e. test type and size of record). This might of
course give use obscure tuple errors instead.
>Actualy I'm quite aware of this, there is a lot of code that
>relies on records being tuples: lists:keysearch, ets tables,
>code change code in the AXD301 ... so I can't say that I expect
>the implementation to change.
Of course, functions like lists:keysearch() and ets:insert() et
al would have to support operations on record types.
lists:keysearch(Key, #myRec.key, List)
should work as expected on true record types.
Code change functions should be possible to ignore, since it's
difficult to write a generic code_change function that works
independently of what's changed in the code. IOW, one has to
write a specific code_change function for each upgrade.
There _shouldn't_ (tm) be that much code that breaks the record
abstraction. One problem is that it's difficult to find those
instances that do... One way is of course to run the system until
it breaks, but that approach leaves something to be desired.
Personally, I'm in favour of making records a real data type,
but if pressed, I'll deny I ever said that. (: