Elm warns about name collisions. This is why I was asking Will about the context.
I sometimes don't care about name collisions, I import multiple modules unqualified and just disambiguate at the top of the file. It is wrong, stupid and it should not be done but sometimes I do that :) . I know it is something I can fix after I'm done with the functionality. On Wed, Jul 20, 2016 at 8:36 PM, Nick H <[email protected]> wrote: > I would love a compiler warning for this. It already warns about unused > imports. Warning about naming collisions would be in the same spirit of > encouraging code quality. > > Even with the warning, this is a good reason to use unqualified imports > sparingly. If the package name is long or I use it frequently, I might > shorten the name (for example "import Data.Integer as Int"). But I almost > never import functions without a namespace. > > The Elm documentation warns that unqualified imports are a bad idea, but > this warning is hidden in the API Design Guidelines > <http://package.elm-lang.org/help/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. >> > > > > > On Wed, Jul 20, 2016 at 8:54 AM, Peter Damoc <[email protected]> wrote: > >> Will, >> >> did you import elm-integer's toString and it did not give you an error >> about the duplication? >> >> This sounds unexpected. Do you have a SSCCE showing this kind of problem? >> >> >> >> >> >> On Wed, Jul 20, 2016 at 5:12 PM, Will White <[email protected]> >> wrote: >> >>> Just to be clear, in 1. I did `toString Integer`, expecting that to >>> call elm-integer's toString, not Basic.toString. >>> In the first bullet point, I meant to say "...even though `toString >>> Integer` is valid...". >>> >>> >>> On Wednesday, July 20, 2016 at 3:04:23 PM UTC+1, Will White wrote: >>>> >>>> Coming from >>>> https://github.com/elm-lang/error-message-catalog/issues/135, I'd like >>>> to know what you think we could do about ambiguous uses of e.g. `toString`. >>>> For instance: >>>> >>>> >>>> 1. I was using elm-integer, which has its own `toString` function >>>> for its massive integers, and I called it on an elm-integer Integer. >>>> 2. My code *actually* called `Basics.toString` on the Integer, so >>>> the result was not as expected. Luckily I caught it. >>>> >>>> I can think of two ways to handle there being more than one toString >>>> around: >>>> >>>> >>>> - Warn the developer that the use of `toString` is ambiguous, even >>>> though `Basics.toString Integer` *is* valid (Basics.toString >>>> changes *any* type to a String). Namespacing the toString would >>>> make the warning go away. >>>> - Call the toString that's in the same module as the type of the >>>> argument is in, i.e. the toString that's in the same module as Integer. >>>> >>>> I'm sure this will affect other functions as well as `toString`. >>>> >>> -- >>> 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. >>> >> >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> >> -- >> 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. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
