On Sunday, February 5, 2017 at 9:37:54 PM UTC, Keith Lazuka wrote: > > Why should the `Period` state be hidden with an opaque type? If you're > writing a library, then, yes, it makes total sense so that you can avoid > having to make major version bumps as the library evolves. But if this is > an application-specific component which will only ever be used *within* > this project, then you might not need the encapsulation. >
I think hiding the Period Type in this way is unnecessary - even in libraries Types are often not concealed. For example, the Maybe type is not made opaque - it could be, with functions to test whether a maybe isNothing or isMaybe. But it is useful to expose the Maybe type in order that users of it can pattern match on it and more easily implement their own functions that operate on it. Another more complex example might be elm-multiway-tree-zipper, which does not conceal its Tree and Zipper types. All the better, because I have written functions that work with these types to implement operations that this library does not provide. A Type is a static thing and it needs some functions to do useful stuff with it and bring it to life. I am leaning towards bundling together a Type and its core operations into a module, but fully exposing the Type. Consumers of the module can treat it as opaque if the operations cover off everything you need to do, but can also deconstruct the Type if they need to. That said, if I have a nested TEA module, I will always make its Msg type opaque by not exposing its constructors. This is because the consumer of this module just needs to forward its events to it, without knowing what they are. If it was not for this, then the Msg type could be completely hidden. -- 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.
