The module's interface is an entity unto itself. When I am visiting unfamiliar code, I often want to know what its API looks like. Having everything there at the top is way easier than having to scan through search results for Ctrl-F "exposed".
It also helps with design. Seeing the entire interface written out in one place helps you recognize what's missing, what's redundant, what's unnecessary. Plenty of times in Java land, I would run into methods that didn't have the appropriate access modifier. That sort of thing is much easier to spot and fix when it's all in one place. When you are adding documentation to the module, the table of contents gets defined at the top of the file also. (The functions can be organized differently in the docs than they are in the code itself). Once that's there, having the API listed there makes more sense. On the other hand, with the documentation in place, your function names are repeated in *three* places. Which I admit is kind of annoying when you need to move or rename something. On Wed, Nov 30, 2016 at 9:02 AM, Joey Eremondi <joey.eremo...@gmail.com> wrote: > This is something that is probably solved by having better IDE/editor > tools to manage imports/exports, rather than changing the language. > > The import syntax has gone through many iterations, so I wouldn't be > surprised if it's pretty stable where it is. > > On Wed, Nov 30, 2016 at 8:33 AM, Matthew Griffith <mdg.griff...@gmail.com> > wrote: > >> >> I find exposing functions/types at the top gives a nice summary of what >> is exposed when reading a new module. I can usually get a good idea of how >> the module works by seeing the names of the things that are exposed next to >> each other. That would be harder to do if the exposed annotation is >> throughout the module. >> >> I haven't really noticed the expose syntax as being a pain in >> refactoring/reorganization, though it is an additional step when moving, so >> I see your point. However, in my experience the additional step is pretty >> trivial/quick to handle, especially with the compiler guiding you. >> >> -Matt >> >> >> >> On Wednesday, November 30, 2016 at 9:07:15 AM UTC-5, Martin Cerny wrote: >>> >>> Hi all, >>> coming from Java, C++ and C#, I find the module X exposing (A,B,C) >>> syntax weird - to be short, it feels a bit like C/C++ header files, in that >>> you repeat entity names at multiple places, making refactoring harder. I >>> however guess the syntax was chosen for a reason - so I am asking: what are >>> the advantages of >>> >>> module Foo exposing (bar) >>> >>> bar: Int >>> >>> over something like >>> >>> module Foo >>> >>> exposed bar: Int >>> >>> Hope the answers will help me better understand Elm >>> >>> Thanks >>> Martin >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elm-discuss+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
