Then I'll always namespace them. If I forget one though... On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote: > > 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] <javascript:> > >: > > 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] > <javascript:>> 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 >>> <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] <javascript:>. >> 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] <javascript:>. > 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.
