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] > <javascript:>> 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] <javascript:>> >> : >> >>> 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] <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.
