5 ms·

> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest

> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.

josevalim 10y ago
Can you please expand on this a bit? Your comment is very vague. The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.
jkmcf 10y ago
You'd think they'd learn from Java! Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...
brightball 10y ago
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
- _asummers 10y ago
  In Elixir especially, with everything being immutable, I don't really have to worry about state hanging around for my private methods to care about. I wind up just throwing private functions into little helper modules that can be tested independently. As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.
- swsieber 10y ago
  They seem quite useful. Mostly signaling that things should not be used. What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.
  - brightball 10y ago
    On a single code base, the most I've worked with at a time is 12.
- preordained 10y ago
  There are plenty of times. Take a data structure like a hashmap. You know there are plenty of internal functions to manage the map (rehash, handle collisions...) that there is no reason for a hashmap end user to see or even be tempted to muck with. Now, you can could make a new class as an interface to this hashmap with only the appropriate exposed methods...but that seems like an excessive sort of pattern. In a statically typed language like Java, etc., it also gives you the benefit that when you are auto-completing or discovering methods, you see only the exposed methods you are meant to call as an API user instead of poring over every two-line helper method in the class.
  - true_religion 10y ago
    When I subclass hashmap, I may desperately want to reimplement collision handling without also having to rewrite the every other private function it calls. Private functions close the library off to custom extension.
    - mkarklins 10y ago
      ... and keeps the library's updates smoother, since there can't be any tinkering with library's implementation.
      - true_religion 10y ago
        You don't have to support users who use your library internals. Django for instance didn't support everyone who relied on undocumented internals in its orm. The standardization for the latest release made those internals clean and documented, but unapologetically broke other people's code including mine.
- barrkel 10y ago
  Private functions permit functional decomposition without a commitment to support the interface implemented by the private functions (meaning the functions can be changed / refactored without breaking clients of the library).
- ramchip 10y ago
  Private (a.k.a. non-exported) functions affect how the compiler optimizes code, at least around inlining.
int_19h 10y ago
A function being overridable is a part of the contract, because other functions may rely on it. If you can override truly private stuff, you have no idea about the invariants that you need to uphold to do that correctly.
sch1zo 10y ago
Am I misunderstanding this or what do you mean learn from ruby? In Ruby I can override private methods without a problem.
- pmontra 10y ago
  Ruby doesn't have private methods. You can always object.send(:method) and the only effect of the private keyword is to disable the object.method() syntactic sugar. No wonder that even methods marked as private can be redefined.

josevalim 10y ago

Can you please expand on this a bit? Your comment is very vague. The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.

jkmcf 10y ago

You'd think they'd learn from Java! Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...

brightball 10y ago

Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.

_asummers 10y ago
In Elixir especially, with everything being immutable, I don't really have to worry about state hanging around for my private methods to care about. I wind up just throwing private functions into little helper modules that can be tested independently. As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.
swsieber 10y ago
They seem quite useful. Mostly signaling that things should not be used. What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.
- brightball 10y ago
  On a single code base, the most I've worked with at a time is 12.
preordained 10y ago
There are plenty of times. Take a data structure like a hashmap. You know there are plenty of internal functions to manage the map (rehash, handle collisions...) that there is no reason for a hashmap end user to see or even be tempted to muck with. Now, you can could make a new class as an interface to this hashmap with only the appropriate exposed methods...but that seems like an excessive sort of pattern. In a statically typed language like Java, etc., it also gives you the benefit that when you are auto-completing or discovering methods, you see only the exposed methods you are meant to call as an API user instead of poring over every two-line helper method in the class.
- true_religion 10y ago
  When I subclass hashmap, I may desperately want to reimplement collision handling without also having to rewrite the every other private function it calls. Private functions close the library off to custom extension.
  - mkarklins 10y ago
    ... and keeps the library's updates smoother, since there can't be any tinkering with library's implementation.
    - true_religion 10y ago
      You don't have to support users who use your library internals. Django for instance didn't support everyone who relied on undocumented internals in its orm. The standardization for the latest release made those internals clean and documented, but unapologetically broke other people's code including mine.
barrkel 10y ago
Private functions permit functional decomposition without a commitment to support the interface implemented by the private functions (meaning the functions can be changed / refactored without breaking clients of the library).
ramchip 10y ago
Private (a.k.a. non-exported) functions affect how the compiler optimizes code, at least around inlining.

int_19h 10y ago

A function being overridable is a part of the contract, because other functions may rely on it. If you can override truly private stuff, you have no idea about the invariants that you need to uphold to do that correctly.

sch1zo 10y ago

Am I misunderstanding this or what do you mean learn from ruby? In Ruby I can override private methods without a problem.

pmontra 10y ago
Ruby doesn't have private methods. You can always object.send(:method) and the only effect of the private keyword is to disable the object.method() syntactic sugar. No wonder that even methods marked as private can be redefined.