Or maybe I'm still misunderstanding what your exact problem is in the absence of "exposing (..)". Maybe you can expand on the problem description from your first message in this thread?
> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer > <[email protected]>: > > 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.
