I'm in favor of this proposal. In fact, I proposed something similar awhile back:
https://groups.google.com/d/msg/elixir-lang-core/X18SZnSDW7U/LZm8_8PYBQAJ On Tuesday, December 12, 2017 at 4:12:11 AM UTC-8, Wojtek Mach wrote: > > (I tried sending below message to the list but is still doesn't show up so > if it eventually does: sorry for dup!) > > There is already kind of a notion of protected module in Elixir: a module > with `@moduledoc false`. Such module is e.g. not autocompleted in IEx. > You're right however that all modules are globally accessible. > > I've recently encountered a SO answer [1] suggesting to use undocumented > OTP :ram_file module and a prompt comment that since it's undocumented it > *shouldn't* be depended upon. Thus, I think it's a good idea for xref to > generate a warning in case of calling function from @moduledoc/@doc false > outside of the OTP app. Especially if/when all BEAM languages store > documentation chunks the same way. And of course, apply/3 is an escape > hatch to silence the warning. > > I started looking into adding the warning into xref [2] and it looks > pretty promising. One thing missing is my early implementation still emits > warning for undocumented function even if it's inside the same OTP app - > something I want to fix in the final version. > > [1] https://stackoverflow.com/a/22809265 > [2] https://github.com/wojtekmach/elixir/tree/wm-xref-undocumented > > W dniu niedziela, 10 grudnia 2017 21:34:43 UTC+1 użytkownik Maciej > Kaszubowski napisał: >> >> Hello, >> >> *What?* >> >> I would like to propose introducing a possibility to make a module >> protected/private. Functions from such module would not be visible outside >> of the OTP application they are defined in. >> >> *Why?* >> >> Currently, all modules included in the release are globally visible. This >> makes it harder to enforce correct architectural boundaries because we have >> no support from the compiler. We can only enforce the boundaries by being >> careful or by running external scripts, but both solutions fall short when >> the developers are under pressure or before deadlines. >> >> It would be nice if it was possible to create a module which can only be >> accessed from the inside of a library/application where it's defined. We >> have private functions, so it would be nice if we could do the same for >> modules which are one abstraction level higher. This would allow to clearly >> define a public interface for libraries/applications which would result in >> better design. Since one of the recent Elixir goals is to help creating >> maintainable software, I think this feature would be a really good step in >> this direction. >> >> *Issues* >> >> Proposed behaviour could be problematic due to the fact that all Elixir >> modules compile to Erlang modules which are all public. I came up with >> three possible ways to handle this: >> >> 1. Compile all modules modules as usual (resulting in public Erlang >> modules), but have Elixir compiler fail when the function from >> private/protected module is called. >> 2. Don't create Erlang modules from private/protected Elixir modules and >> "copy" the functions to public modules that use them. >> 3. Treat all modules are public and use mix xref task to validate this >> behaviour outside of the compilation step. >> >> All of the solutions have advantages and disadvantages and maybe there >> are some others which I didn't think of. >> >> I'll be happy to know what you think about this. >> >> Cheers, >> Maciej >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/728fb47d-dab8-452f-af0b-ed761079a325%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
