Structs (was RE: Record selectors)

[Chris Pressey]

On Wed, 15 Jan 2003 10:39:07 +0100 (CET)
Joe Armstrong <joe@REDACTED> wrote:

> [...]
>   Language design *is* (in a sense) choosing which operations should be
> expressed by succinct syntax and efficiently implemented.

That is very important, but it's stage 2.  Stage 1 is deciding which
semantics should be present in the language in the first place.  And I'm
just trying to point out that the struct semantics are essentially already
there in the guise of the dict module.  I don't really have any objections
to having a nice syntax & efficient implementation of dictionaries per se.
(We'd be catching up to Perl.)  I only suggest that it might be smoother
to extend dictionaries rather than to introduce a new concept - structs
are so similar that it's hard to imagine them breaking anything that
currently uses dictionaries.

> [...]
>   My view is that data validation *only* occurs at a human -> computer
> interface and  at a boundary  where two components communicate  via. a
> protocol and where the components are not trusted.

Ah!  I feel very similarly, except my view is that I shouldn't fully trust
*anything* outside the current module - not even my own code, since I'm
human and I make mistakes.  In other words, every module is a boundary
where components communicate with a protocol, even if that protocol is
just a set of exported Erlang functions.

> [...]
>   No encapsulation is fine - but objects (as in OO languages) do a lot
> more than just encapsulate things.

Yet strangely, the definitions Matthias produced are so vague that they
hardly seem to warrant such expectations :)

Anyway - OK, so forget the term "object", it's only a hint at what I mean
(encapsulation), which is why I put it in quotes.

But I don't agree that "no encapsulation is fine."

My experience is that no encapsulation makes it a lot easier for a subtle
bug to hide for a long time, while rigorous encapsulation makes it much
more likely that a subtle bug will be exposed quickly.  (Even if your
validation of 'foreign' data is perfect, invalid data can still be
generated internally by buggy code.)  So, unless performance is utterly
crucial, why chance it?  Even then, do it with encapsulation first, until
you are as positive as you can be that there are no hidden bugs, and only
take it out when you hit the performance wall.

However, if, as you mention in your other message, you're willing to add
guards to structs, I'm all for it.  Whether it's a proper module or a
'lambda module' made up of named funs, it makes little difference, it's
still a "skin" and that's something that I consider highly important.

-Chris