[erlang-questions] Overriding built-in functions in a module

[Robert Virding]

LFE already has this function scoping:

Local functions (to a function)
Functions defined in the module
Explicit imports
Implicit imports from module erln

Seeing it doesn't have the backwards compatibility issues it can do it
without extra compiler options. I definitely think it is the right way
to go.

Robert

On 4 June 2010 12:07, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
> Yesterday OTP-8579 landed on the dev branch.
> It might solve the issue discussed here.
>
> Tests: http://github.com/erlang/otp/commit/b72cac2
> Docs:  http://github.com/erlang/otp/commit/dcd4d82
>
> Merge commit message from
> http://github.com/erlang/otp/commit/09f146a:
> ----8<----
> OTP-8579  Local functions should override auto-imported
>
> Local and imported functions now override the autoimported
> BIFs when the names clash. The pre R14 behaviour was that
> autoimported BIFs would override local functions. To avoid
> that old programs change behaviour, the following will
> generate an error:
>
> Doing a call without explicit module name to a local function
> having a name clashing with the name of an autoimported BIF
> that was present (and autoimported) before OTP R14A
> Explicitly importing a function having a name clashing with
> the name of an autoimported BIF that was present (and
> autoimported) before OTP R14A Using any form of the old
> compiler directive nowarn_bif_clash
>
> If the BIF was added or autoimported in OTP R14A or later,
> overriding it with an import or a local function will only
> result in a warning,
>
> To resolve clashes, you can either use the explicit module
> name erlang to call the BIF, or you can remove the autoimport
> of that specific BIF by using the new compiler directive
> -compile({no_auto_import,[F/A]})., which makes all calls to
> the local or imported function without explicit module name
> pass without warnings or errors.
>
> The change makes it possible to add autoimported BIFs without
> breaking or silently changing old code in the future. However
> some current code ingeniously utilizing the old behaviour or
> the nowarn_bif_clash compiler directive, might need changing
> to be accepted by the compiler.
> ---->8----
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>