Should one wrap a model implemented as a record in a type to keep the
details private? In other words:
type alias Model = { foo : Foo, baz : Baz }
- or -
type Model = M { foo : Foo, baz : Baz }
The former is much easier to work with because one isn't constantly
unwrapping and rewrapping.
The latter keeps code better encapsulated.
I had this discussion with a fellow programmer and he asked whether
immutability makes the encapsulation irrelevant. I argued no because the
exposure of internals means that client code can adopt dependencies on
internal choices — "Just because I have a field named 'foo' doesn't mean I
want a client to know about it" — and more significantly it allows
arbitrary code to create values purporting to be valid Model values. If one
can achieve "make invalid states impossible", that's obviously great but in
practice we rely on limiting construction to impose further invariants.
(For example, if the structures implementing an AVL tree were exposed, the
type system would ensure that we had a DAG but it could do nothing to
ensure anything about ordering or the height values.)
The balance we were left with was that "we're all programmers of good
character and we will consider other modules Models to be opaque even if
they aren't." (I'd have said "we're all gentlemen" but that's sexist.)
This, of course, works until we hire a programmer whose character isn't
quite as good in this regard.
How do others choose in this regard?
Mark
P.S. What I would like — though it would break a lot of existing code — is
for the fields of a record to only be exposed on export if explicitly
exposed a la exposing constructors for types.
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
