Huh, you are right. Well, now I am confused too. I must have been thinking of the situation where you define a function that reuses the name of an imported function.
On Wed, Jul 20, 2016 at 11:06 AM, Peter Damoc <[email protected]> wrote: > 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. > -- 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.
