You won't be able to forget one if "exposing (..)" is eliminated from the language, as is proposed in the issue I linked to.
You'd then either have to qualify or add the entities explicitly in "exposing (concrete entities)". Problem solved, because in both cases a reader of the code does not need to wonder too much where any given name comes from. > Am 18.08.2016 um 22:19 schrieb Will White <[email protected]>: > > 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]>: >>> >>> 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. -- 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.
