Record selectors

[Chris Pressey]

On Sun, 12 Jan 2003 09:42:00 +0100
"Daniel Dudley" <daniel.dudley@REDACTED> wrote:

> Thanks for your imput, lads. I think I'll conclude that
> Erlang's implementation of records is a mess (a wart on
> Erlang's bottom as Matthias puts it) and thus best avoided.
> They must be a big embarrassment to Erlang. In fact, I
> should think it would be a great service to the community
> if records (in their current form) were phased out as soon
> as possible. Call it an experiment that went horribly wrong.

I'm not so sure.  Take file:read_file_info/1.  If it didn't return a
record, it would have to return a plain tuple or list (lower level of
organization, easier to make mistakes) or a dictionary or object of some
sort (slower - not much slower, but considering that read_file_info is
likely to be called in an inner loop, and that Erlang is supposed to be a
language for real-time processing, it could be significant).

> Chris proposes that country (for example) be a real,
> unique, opaque type that couldn't be confused with any
> other type.

It's actually easy to make opaque values in Erlang (references) but you
can't match on them in case statements, at least not in very many useful
ways.  Ideally I think you'd like to be able to say 'when type_of(X) ==
country' or something like that.  As a workaround, you could say 'T =
type_of(X), case ... when T == country', I suppose.

> I couldn't agree more; record is a type that
> has specific subtypes. This is analogous to objects, which
> are derived from an abstract base object.

I'm also not sure about that.  A record is merely an implementation
measure - it's not a supertype in the same way that Animal is a supertype
of Mammal.  Nothing is really inherited from a record.  Sure, you can
think of all objects being subclasses of a single Object class at the top
of the tree, but that doesn't really give you anything useful in a
dynamically-typed language.

> Clearly
> implementable (efficiently and safely) without use of
> 'orrible syntax.

Sorry, I'm not sure what you're referring to here.  Essentially, you can't
increase the safety of records without also reducing their efficiency -
unless you turn Erlang into a statically-typed language...

> I'm disheartened now, but I do remain hopeful of soon-to-be
> encouraging changes.

Well, the most likely changes in this regard are probably:

a) someone develops a good system for representing objects in Erlang, and
it becomes fairly widely adopted.  This is essentially how Perl has done
it - there's no 'real' support for objects in the language itself, but
there is a sanctioned way of representing them.

b) someone takes all these ideas and develops a new Erlang-like language
without as many blemishes.  The design of such a language would probably
be straightforward, but its implementation would be a massive undertaking
(in which Ericsson wouldn't be expected to have much interest, naturally.)

In the meantime, I still think the best bet is to roll your own objects. 
If, in doing this, you make a consistent system that's simple and
efficient and general enough that it fulfills the requirements for a), all
the better.

One of the better starting points for this I've found is how GS organizes
widgets, using gs:config/2 and gs:read/2 to get and set their properties.
I've extended this significantly, but in rather specialized and
experimental variations which support fancy things like 'active values',
and certainly not everyone needs or wants features like that (didn't work
out too well what with the incremental error creeping into floats
anyway...)

It should also be possible to implement subclassing by intercepting the
'this function doesn't exist in this module' error, and trying to call the
function of the same name in the module of the parent class.  But, I
haven't looked into this yet.

-Chris