More importantly, maybe, you will have to *remember* to use each imported function at least once in qualified form in each module, or you will end up in the situation Nick described, where in six months you don't know (and other readers of your code do not even know the next day after you wrote the code) where reticulateSplines comes from.
> Am 18.08.2016 um 20:03 schrieb Nick H <[email protected]>: > > Is that a good idea? It seems like occasionally, but not always, using the > namespace would make your code less readable than not doing it at all. > > >> On Thu, Aug 18, 2016 at 9:37 AM, Will White <[email protected]> wrote: >> I can still namespace functions with import exposing (..). >> >>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote: >>> 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 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. > > -- > 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.
