[erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479)

[Pedram Nimreezi]

To recap and summarize a flurry of -1's on this feature that appeared on github:

The removal of the check_inheritance code and other experimental
features was much heralded, and exemplified the OTP team's
understanding that Erlang does not need OOP or want incompatibilities.
The addition of an undefined function handler, however, boiled down to
it being a highly experimental feature that should not have been added
or even documented, in many peoples opinion.
Nearly 80% of the people responding to this patch did not agree that
this implementation would add value to Erlang and worse could
significantly degrade the ability to reason about code behaviour.
In the end the only valid use case demonstrated for being able to call
a function which is not defined is in the case of a database ORM where
one would called Person:first_name().
In fact, this one use case (not at all sufficient to warrant this
feature) can easily be implemented by actually generating code created
from data tables schemas and not dynamically determining it.
Experienced programmers will understand the noxious influence of
spooky action at a distance and other idioms from the non-functional
programming world and this simply begs to be used that way.
There is just no room for this type of deferred judgement in a
language specifically designed for the highest levels of program
expectation, scalability and ease of code readability.

Beyond all conceivable objections the most apparent reality is that
calling a userland module function that does not exist is an error,
and trying to "recover" that error is programming defensively.
This very concept alone violates in some way at least half a dozen
long standing Erlang programming rules and semantics [1]..

Such as:

3.5 Don't make assumptions about what the caller will do with the
results of a function
3.10 Try to eliminate side effects
3.11 Don't allow private data structure to "leak" out of a module
3.12 Make code as deterministic as possible
3.13 Do not program "defensively"
4.1 Separate error handling and normal case code
6.7 Exporting functions
7.6 Function names

[1] http://www.erlang.se/doc/programming_rules.shtml#HDR11


-- 
/* Sincerely
--------------------------------------------------------------
Pedram Nimreezi - Chief Technology Officer  */

// The hardest part of design … is keeping features out. - Donald Norman