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

[Pedram Nimreezi]

I will unfortunately repeat myself as for what seems years I've been
complaining
about the absurdity of parameterized modules and the facilitation of
inheritance code in erlang. Furthermore, had these internal OTP
development forums been available to the community or if there
were an OTP channel on IRC or at least public notes on the
direction OTP is going with this, it would be less of an issue or a shock.

Since I couldn't even find the information on said presentation with
out asking around and since it's apparent that no one commenting
here https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d
did either, I have to point out the incredible disconnect between the
OTP team and the community..

However I can honestly say that since R13 when there was likely
far less code reacting with Issue 4 there has been an increase in its use:
- The board acknowledges that a lot of software relies on this feature
  although it's always been experimental.
Just think if a property manager leaves a block of foreclosed homes empty for 5
years or more, how can they be surprised that they might be
illegitimately occupied?

And just like records not being a first class type, which makes records
*indistinguishable* from tagged tuples; This problem was not less apparent
a long time ago, and is only more apparent and tangled today.

And it is *not* like this wasn't obvious at least 5 years ago with posts such as
http://www.lshift.net/blog/2008/05/18/late-binding-with-erlang
Advocating what can only be construed as a tumbling back slide into OO.

- Error handler functionality that today supports inheritance will be slightly
  generalized, so that parameterized modules can contain stubs to facilitate
  inheritance. The functionality in the error handler will be documented.
Facilitating inheritance is not the way to go, it is the way to integrate
all the external problems of OOP by programmers who have yet to grasp
why ROK [1] and Joe Armstrong [2] have stated Erlang is not OOP for a reason.
Adding stubs for it, putting it on the table and saying don't use it
around OO addicts
*is* irresponsible. What people want to do should never relax what the OTP team
demonstrably knows best about building high quality systems. They wrote these
rules and semantics and if they change them now they will lose their
loyal audience
of understanding programmers to compromise with those who have yet to learn from
their mistakes or embrace Erlang's established methodology for
building systems.

- A parse_transform handling source code implementing a parameterized module
  will be published in the public domain, free to use and include in
any package
  needing it. It will however not be part of OTP. As it uses supported
and documented
  functionality, it will however be expected to work for forthcoming
releases as well, or
  at least to be possible to adopt to forthcoming releases.
Requiring someone to override the global error handler to do this is
more responsible,
rather than putting out a yet to be released parameterized module
parse transform
that will be unsupported, but yet adding a feature hook to hang it on.
To quote Charles H. Moore:
  "Do Not Speculate! Do not put code in your program that
   might be used. Do not leave hooks on which you can hang extensions.
   The things you might want to do are infinite"

This is how the undefined function should look... hack it to infinity,
but on your own:

undefined_function(Module, Func, Args) ->
    case ensure_loaded(Module) of
        {module, Module} ->
            case erlang:function_exported(Module, Func, length(Args)) of
                true ->
                    apply(Module, Func, Args);
                false ->
                    crash(Module, Func, Args)
            end;
        _Other ->
            crash(Module, Func, Args)
    end.


- As I remember it we got mainly positive reactions regarding this
decision and now we
  have implemented it exactly as said.
I understand that, but how big was this audience? And where was it held?
Was it perhaps posted on erlang.org with an interactive comments section?

- As a consequence of removing parameterized modules from OTP we have
changed the
  error_handler by removing a built in knowledge about parameterized modules
Wonderful, this made me so happy.

- and by adding a more general and useful functionality, the
$handle_undefined_function feature.
Ugh, this is syntactical sugar, it takes a step forward and then two
backwards- this is sad.


- This feature is useful in a number of situations where one was
earlier forced to modify the global error_handler:
To do unsupported things you naturally should be forced to modify the
global error_handler and support it yourself.

- Can support the parse-transform for parameterized modules (the
-extends attribute)
Since one is forced to transform their modules in an unsupported way anyway,
you should have no trouble also using an unsupported error_handler
supplied with an unsupported parse transform.


I've said my peace, the majority of valid uses here are for testing
and can be restricted to that..
A stern warning is not enough, theres a warning about using process
dictionaries and yet
they are used widely in Erlang itself and a lot of good can come from
them, but not this.

I hope people do not stay neutral on this subject and at least think
take a moment and reflect on this situation.


[1] Erlang is *NOT* an object oriented language.
     That's deliberate:  the inventors of Erlang were well aware of OO
     and chose not to use it.
http://erlang.org/pipermail/erlang-questions/2013-January/071901.html

[2] Why OO was popular?
     Reason 1 – It was thought to be easy to learn.
     Reason 2 – It was thought to make code reuse easier.
     Reason 3 – It was hyped.
     Reason 4 – It created a new software industry.
     I see no evidence of 1 and 2. Reasons seem to be the driving
force behind the
     technology. If a language technology is so bad that it creates a
new industry to
     solve problems of its own making then it must be a good idea for
the guys who
     want to make money.

On Wed, Jan 23, 2013 at 7:06 AM, Ulf Wiger <ulf@REDACTED> wrote:
>
> On 23 Jan 2013, at 12:47, Håkan Mattsson wrote:
>
>> Depends on what you mean with "allowed". With open source code
>> you are "allowed" to do a lot. This does not necessarily mean that
>> it is a good idea to do it.
>
> Nor that you *have* to do it. :)
>
> I think that Kenneth has presented a pretty good argument
> for why they want to introduce this functionality, and also
> reminded us that their past decision was received
> favourably.
>
> We should not feel forced to make clever uses of this new
> feature, just because the OTP team feels that it is needed
> at their level. Even so, if we do feel so compelled, you are
> definitely allowed to. ;-)
>
> BR,
> Ulf W
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>



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

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