Guard test breaks the opacity of its argument

In my mind an opaque type is the equivalent to the OO design guideline that all instance data should have non-public access.

In OO one motivating factor is that you don’t want anything but the instance methods mutating the instance data. In a world where everything is immutable by default that really isn’t an issue which explains to some degree why functional languages can rely on plain data structures so much.

However direct access of the client to the data to the internal organization of the data structure still couples the client to that specific organization.

An opaque type breaks that type of coupling as the client is now forced to use the functions that are supplied with the data structure to extract any information.

When done right an opaque type can give the freedom to radically change the implementation while keeping the API of client facing functions stable (example - here names could be typed as @opaque).

2 Likes