Christian Maeder <[email protected]> wrote: > > So please, please, please, if you decide to use a newtype, do /not/ > > hide the constructor. > > The better alternative to "not hiding the constructor" is to supply > conversion functions that may or may not do more than the constructor > and selector and are named accordingly. (This just disallows pattern > matching.)
Except annoying library users, what would be the point of that? Please understand that as a middle level developer (abstractions, protocol implementations, frameworks, etc.) I am sometimes annoyed by the idealism of some library interfaces, and I find myself reinventing the wheel very often, because the closed interfaces of some existing libraries just don't support what I need, even though the technical basis would be there, or because of the abstraction forest I'm unable to guarantee or even get good performance. I could totally understand having a black box interface for some higher level stuff, but ByteString is still low/middle level and should support me as a developer on that level. Unifying vector and bytestring sounds like a great step, and I would find it ruined already by wrapping it up in a newtype. Hiding the constructor would make this even worse. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
