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.

Replying to

and

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.

12:06 AM · Jun 7, 2021Twitter Web App

Replying to

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++.

Brendan Zabarauskas

@brendanzab

Jun 7, 2021

The issue is when it causes ecosystem damage. Like builds not compiling etc. for downstream consumers. So yeah if those kinds of schenanigans are happening it should be tracked in the versioning system somehow.