Structs (was RE: Record selectors)

[Chris Pressey]

Thanks to everyone for your sanity check.  :)

On Wed, 12 Feb 2003 10:12:27 +0100 (MET)
Ulf Wiger <etxuwig@REDACTED> wrote:

> On Tue, 11 Feb 2003, Chris Pressey wrote:
> 
> >To me, OO just means code and data (state) are grouped in
> >units.  All the other tenets I've seen seem to follow from
> >that principle.  Erlang modules currently work fairly well
> >for the purpose, and with enough effort I'm sure any OO
> >technique could be implemented on top of them; but more
> >usually, I'll bet Erlang programmers just code up discrete
> >abstractions to serve the specific purposes they have in
> >mind right then.
> 
> I fully agree.

After catching up with all the traffic, several things come to mind. 
Apologies in advance if this degrades into a brain dump, they seem popular
these days.

I think Erlang programmers like to be able to re-invent the wheel, in my
opinion because many of them recognize that a) like snowflakes, no two
wheels are really the same anyway, and b) subtle qualities in development
can affect the character of an entire product.  Yet as programmers we also
want a nice, standard, stock, off-the-shelf wheel available - when it is
just the thing.

At least one author I've read has quite literally stated that reusability
is the holy grail of OOP.  But my experience is that when writing a
software component you can never fully predict how you will be forced to
use and extend it in the future.  Reusability is very important, but good
quality software ought to be the real holy grail of any sane programming
school of thought.

Having said that: reusability is very, very important.

My thought is, at least some of these vaguely OO-ish abstractions that
Erlang programmers code must be commonplace and sufficiently general and
should be factored out - either in a gen_* module or as features of the
language (or the preprocessor.)

One problem is that there are so many possible ways to live up to any
number of 29 criteria.  In this respect, Erlang is a good OO language
because it *doesn't* force you into a one-size-fits-all object framework -
it just doesn't have one!  How do you begin to explain to marketing that
an absence of a feature is a selling point?  :)

Having no object model strikes me as better in the long run than keeping
track of 1<N<2^29 different gen_object modules, anyway.

But for language features, this essentially dovetails with structs - find
the single most common and most useful abstraction that programmers code
for, under the general heading of 'structured data', and make it a
language feature.  Make sure it's what people use most of the time, make
sure it's actually useful, give it an optimized implementation and it's
own syntax.

> [...]
> >Am I a freak, or do other people find that it helps to
> >write modules this way - basically, to hide each data
> >structure behind interface code? Would structs obsolete
> >this discipline, and if not, how could they be enriched to
> >do so?
> 
> I think structs can simplify this type of programming. The
> main difference between structs and records in this recard
> is that with records, you have to have explicit access
> functions for each type of record. Thus, if you wanted to
> reuse the pattern above for another geometric shape that
> also has width and length, and something else (...ehhm, say
> a gable roof -- width, length, rise,
> http://www.themetalman.net/roofshape.htm), you could reuse
> some of the code above, probably skipping perimeter/1, but
> you'd still have to change most of the code since it
> specifically refers only to a _rectangle_'s width or height,
> not just the width or height of any shape. This makes it
> more difficult to write generic support functions when
> records are involved.

Well, structs give us something like dictionaries with callback
functions on some events like setting or retrieving an entry.  To view the
world through a Perl filter - they're a lot like tied hashes...

Modules are a convenient place to put functions like 'perimeter', but I
suppose there's no reason they couldn't be funs in the struct itself.

In fact, I think structs might have an advantage of being defined with
funs.  Erlang grew up with callback modules, but consider a 'lambda
module' which is just a dictionary of funs.  Instead of being named
functions, they have keys that are each an atom.  The advantage over a
regular module is that the lambda module can have a higher order -
constants can be curried into the funs.

> Structs would make this easier, because you can e.g.
> stipulate that a given struct should have certain attributes
> for a certain function to work. You could even, if you relax
> the performance requirement a tiny bit, inspect the struct
> to find out if Area should be calculated based on
> {width,height}, {width,height,rise}, or radius. OK, a fairly
> contrived example, but you get the picture.

If the struct has a callback for what to do when an undefined field is
accessed, this could make things like this very easy: supply a callback
that implements inheritance or delegation or what have you.

-Chris