Yes - but at the same time I think the sometimes obsessive concern with extensibility and reuse is what has gotten the practice of OO into trouble.
Seems to be a direct consequence of Chapter 13: Programming Erlang 2e:
In Erlang we have a large number of processes at our disposal, so the failure of any individual process is not so important. We usually write only a small amount of defensive code and instead concentrate on writing corrective code.
…
The Erlang philosophy for building fault-tolerant software can be summed up in two easy-to-remember phrases: “Let some other process fix the error” and “Let it crash.”
This seems to give rise to a tenet of relying on a set of well-defined, pre-selected contingencies whenever a “you can’t get there from here” situation arises - rather than expending effort on trying to micro manage the error response based on a plethora of detailed error information that may or may not be available.
An error occurs:
- let’s give up OR
- let’s try again again later OR
- let’s try something entirely different
You can’t get any more loosely coupled than simply responding to the presence of the error while not depending on any of the details about the error.
And once even a single client depends on that field you’ll break it when you need to take it away again or move it, i.e. by offering too much detail you are limiting your own potential for future change without breaking things outside of your own boundary. Too much detail can be just as damaging as too little - possibly more so.
