I try to answer myself the question whether or not a type is going to be
exposed (used by client code) or if I just want to wrap some fields into an
alias for convenience.
As soon as a type becomes exposed, I prefer strong types because of their
stricter contract. Also, strong types are easier to extend in hindsight
without breaking other code. If I would add another constructor "M2" to
your "type Model", I wouldn't have to worry about client code that uses
"M". First, I didn't really appreciate the necessity to expose constructors
explicitly, but I actually like that fact because it allows me to NOT
expose constructors and instead expose custom functions for client code to
interact with a type. This allows you to change the internals of a type
without breaking client code.
Still, type aliases can be convenient to juggle logical units of fields
internally.
On Thursday, March 23, 2017 at 5:21:10 PM UTC+1, Mark Hamburg wrote:
>
> 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.
