Conversation

Unpopular opinion: information hiding should be opted into by the consumer, and not forced by the producer.

Quote Tweet

· Jun 6, 2021

Outside of parametricity I haven't found an information hiding mechanism that's doesn't turn out to a giant pain later on for all parties. Hide it behind some kind of forall or make it public.

Brendan Zabarauskas

@brendanzab

Jun 7, 2021

Heh, I disagree I think? I think it's important to at least ensure at the package repository level that packages don't depend on stuff that may later be change (in conflict with their versioning expectations). We shouldn't need things like stackage to stay on top of breakages.

Brendan Zabarauskas

@brendanzab

Jun 7, 2021

I do agree that it would be cool if versioning could be finer grained than semver for an entire package though. But yeah, it's important for library authors to be able to have the room to change internals.

Miëtek Bak

@mietek

Jun 7, 2021

By opting out of information hiding, the library user takes on the responsibility of keeping up with changes to internals. This is already how things work in assembly languages such as C or C++.

Miëtek Bak

@mietek

Jun 7, 2021

I should have said “by not opting in” to stress that information hiding should not be the default.

Brendan Zabarauskas

@brendanzab

Replying to

@mietek

Yeah, I guess I'm talking more about the Haskell approach of having an 'Internal' module that could break at any time…

4:23 AM · Jun 7, 2021Twitter Web App

Replying to

and

If we can figure out upgrade package versioning to allow us to be more flexible with how we couple stuff and expose those choices as metadata to a version resolver, then I'd be more open to the idea.