1. 7
  1. 3

    Is this calling a private function or is it calling a public function with source identical to a private function? Is this a distinction without meaning in Erlang?

    1. 2

      It’s recompiling a module so that all functions are in fact “public” (i.e. exported), including previously “private” (un-exported) functions. Which isn’t the same as calling a private function from outside the module; by the time you call it here, it’s not private. Like @doug-moen says, it’s showing something about how you can dynamically recompile and hot-reload code in Erlang, which is rad for iterative development and live upgrades (though the upgrades get more complicated than I’ve ever dipped far into if you change data structures), but inevitably leads to this kind of thing. That’s all a part of the tooling, so I wouldn’t really see this as some kind of shady way of exposing supposedly private functionality but more a compromise that you have to make to get this kind of flexibility.

      1. 1

        It’s recompiling a module so that all functions are in fact “public” (i.e. exported), including previously “private” (un-exported) functions. Which isn’t the same as calling a private function from outside the module; by the time you call it here, it’s not private.

        Right that’s what I am getting at. If there was a way to call a private function in Erlang that wasn’t “automate copy pasting the code”, would you be able tell the difference? I feel like the answer is no because there are no module scoped variables etc., whereas in python if you cloned a module to publicize a private function you could observe the difference between calling the copy and calling the original.

        1. 1

          There should be no difference.

    2. 1

      This is a special case of a more general principle. Adding powerful metaprogramming features to a language allows you to violate abstraction boundaries and negate guarantees that those abstraction boundaries enforce. It’s like how the unsafe features of Rust allow you to write code that violates the by-default “safe” language semantics.