> I'm not in favour making decision in IEx base on *@moduledoc false* or *@doc false.*
Me too. I think the point Myron's proposal got is much more interesting. Read the thread for details: https://groups.google.com/d/msg/elixir-lang-core/X18SZnSDW7U/LZm8_8PYBQAJ On Thursday, January 4, 2018 at 1:13:41 PM UTC-2, Milad Rastian wrote: > > I'm not in favour making decision in IEx base on *@moduledoc false* or *@doc > false.* > > When someone uses them in a current project they won't be able to quickly > check the module in IEx and has to enter the full module name or function > name. > > I understand your needs. However strongly believe that using > doc attributes is not a proper way. The intention of doc attributes is to > provide document not "hiding" it from others. > > If it's decided to go on with this feature I recommend to use different > macro(in compare to def and defmodule) or different module attribute. > > > > On Friday, December 15, 2017 at 7:12:06 AM UTC+1, Myron Marston wrote: >> >> 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/1df449f0-0b71-4a57-9c51-3d0c76f6f13a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
