If you prefer not having to remember things, then you should use qualified imports.
Stripping the namespace off of all your imported functions means that your code no longer tells you where these functions come from. You will have to remember this information yourself. This doesn't seem like much of a mental burden at the moment, but it will likely become much more burdensome in 6 months when you are reading through your code again (e.g. "Now, which of these 10 modules did that 'reticulateSplines' function come from?") And if you never run into that annoyance, I guarantee that every other person who reads your code will. What's more, APIs that follow the design guidelines <http://package.elm-lang.org/help/design-guidelines#naming> are going to make your life even harder, because the functions will have names designed to work with a qualifier. Look at your own example. If "toString" only works on one type, then it is a terribly undescriptive name. But if the module is named "Foo" and the type defined in that module is named "Foo", then "Foo.toString" is not a terrible name. >From the design guidelines: > A function called State.runState is redundant and silly. More > importantly, it encourages people to use import State exposing (..) which > does not scale well. In files with many so-called "unqualified" > dependencies, it is essentially impossible to figure out where functions > are coming from. This can make large code bases impossible to understand, > especially if custom infix operators are used as well. Repeating the module > name actively encourages this kind of unreadable code. > With a name like State.run the user is encouraged to disambiguate > functions with namespacing, leading to a codebase that will be clearer to > people reading the project for the first time. A great example from the > standard library is Bitwise.and > On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer < [email protected]> wrote: > I can’t search for the thread right now, but I’m sure you can find it > yourself via the archive. In any case, one aspect of it (but I think there > were more) was this: https://github.com/elm-lang/elm-make/issues/61 > > > 2016-08-18 17:08 GMT+02:00 Will White <[email protected]>: > >> What unexpected results? The compiler has your back if two unqualified >> functions have the same name. >> >> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote: >>> >>> That's not an answer to my question I understand as a problem >>> description. >>> >>> Also, there have been earlier threads here that have discussed what can >>> go wrong if you unwittingly import with exposing everything. So, where not >>> remembering that one of those imports brought a certain function name into >>> scope, lead to unexpected results. If your concern is valid, theirs is at >>> least as much. >>> >>> Am 18.08.2016 um 17:48 schrieb Will White <[email protected]>: >>> >>> You have to remember to qualify. >>> >>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer >>> wrote: >>>> >>>> In what ways are qualified imports at odds with safe code? >>>> >>>> I think the opposite is the case: unqualified imports lead to less code >>>> safety. >>>> >>>> Am 18.08.2016 um 17:37 schrieb Will White <[email protected]>: >>>> >>>> I prefer safe code to qualified imports. >>>> >>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote: >>>>> >>>>> "Qualified imports are preferred." >>>>> >>>>> http://elm-lang.org/docs/syntax#modules >>>>> >>>>> I try to avoid as much as possible importing everything from a module. >>>>> If I would have IDE support for automatic imports I would never do a >>>>> import >>>>> Module exposing (..). >>>>> >>>>> -- >>>> 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 [email protected]. >>>> 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 [email protected]. >>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
