[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?
Namespacing everything actually makes import redundant. No more imports if you like to namespace everything. Then make import exposing (..) the new import. Well up for that! On Thursday, August 18, 2016 at 2:33:25 PM UTC+1, Will White wrote: > > import ModuleWithToString > > toString typeFromThatModule > > Compiles with unexpected results that you have to catch. > > import ModuleWithToString exposing (..) > > toString typeFromThatModule > > Doesn't compile: "use of toString is ambiguous: did you mean > Basics.toString or ModuleWithToString.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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?
Edit: I did some searching after I posted this and realized just how common it was to have custom toString functions, so I take back what I said about not naming your own functions toString. Switching Basics.toString to Debug.toString could be a good solution, although that would be annoying for simple cases like converting an Int to a String (which is often needed in non-debug situations like setting up HTML/SVG attributes). Maybe there should be a specialized Int.toString function instead. I do think it's a sufficiently special case that 'always import qualified' is still the best strategy though. On Friday, 19 August 2016 09:28:56 UTC+10, Ian Mackenzie wrote: > > It seems to me that the issues you are encountering come from two things: > >- Using a mix of qualified and unqualified imports >- Having a function the same name as one in Basics > > One solution is to never use qualified imports, but a better solution is > to *always *use qualified imports and just not name any of your own > functions toString (or min, or max, or degrees, or anything else in Basics > ). That way you never have any ambiguity between functions, you never > have to switch between qualified and unqualified (if, perhaps, you start > using Maybe.map in a file that already uses List.map), and it's always > clear where a function (or value) is coming from. > > On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote: >> >> import ModuleWithToString >> >> toString typeFromThatModule >> >> Compiles with unexpected results that you have to catch. >> >> import ModuleWithToString exposing (..) >> >> toString typeFromThatModule >> >> Doesn't compile: "use of toString is ambiguous: did you mean >> Basics.toString or ModuleWithToString.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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?
I won't go so far as to say that (..) imports should be removed from the language but I'm definitely on the side of rarely using them for reasons that have been cited repeatedly in this thread. Furthermore, having written several data structures in Elm, you want to keep names like map available for you to define yourself. So if you see map with no qualifier, it's the map for this data structure, defined in this module. -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?
It seems to me that the issues you are encountering come from two things: - Using a mix of qualified and unqualified imports - Having a function the same name as one in Basics One solution is to never use qualified imports, but a better solution is to *always *use qualified imports and just not name any of your own functions toString (or min, or max, or degrees, or anything else in Basics). That way you never have any ambiguity between functions, you never have to switch between qualified and unqualified (if, perhaps, you start using Maybe.map in a file that already uses List.map), and it's always clear where a function (or value) is coming from. On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote: > > import ModuleWithToString > > toString typeFromThatModule > > Compiles with unexpected results that you have to catch. > > import ModuleWithToString exposing (..) > > toString typeFromThatModule > > Doesn't compile: "use of toString is ambiguous: did you mean > Basics.toString or ModuleWithToString.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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
