It is something I have to worry about, because having 50+ useless functions with names like "id" and "title" imported into my default namespace is a recipe for naming collisions and confusing compiler errors.
Supposing Html.Attributes had a function called "toString" that I didn't know or care about? Your proposal sounds like it will take the problem you are trying to solve and just make it worse. On Fri, Aug 19, 2016 at 2:13 PM, Will White <[email protected]> wrote: > That's optimisation work that should be done by the compiler. The fact > that class is only one of an arbitrary number of functions in > Html.Attributes isn't actually something the programmer should have to > think about. The compiler would look at the Html.Attributes you use in your > file, find only class, and do whatever import exposing (class) does now. > > On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote: >> >> Will, how would you propose to deal with selective imports? For example: >> >> import Html.Attributes exposing (class) >> >> This is a frequent usage for me. Html.Attributes has a bazillion things >> in it, and a lot of them are common words. I want to de-namespace "class" >> because I use it frequently, but not the rest of that junk. >> >> >> >> On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi <[email protected]> >> wrote: >> >>> I had suggested something similar a while back: >>> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M >>> >>> The arguments against it are still valid. >>> >>> I don't think there's widespread dissatisfaction with the import system >>> as of 0.17, so I doubt it will change any time soon. >>> >>> On Fri, Aug 19, 2016 at 1:37 PM, Will White <[email protected]> wrote: >>> >>>> I have an idea that I think is nice. Make writing List.map actually >>>> *do* what import List exposing (map) does, so you don't have to write >>>> import List at all. And if you want to use a function without a namespace, >>>> e.g. Html, import Html could do what import Html exposing (..) does now. >>>> >>>> >>>> On Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote: >>>>> >>>>> Since 0.14, I have been hearing more complaints about imports. Lots of >>>>> different proposals and discussions. Beginners struggling to understand >>>>> how >>>>> the different variations fit together. After hearing Laszlo's take on >>>>> this, I >>>>> am trying out a new syntax and semantics >>>>> <https://github.com/elm-lang/elm-compiler/commit/2234b88396395ec8633b20a4af5261517059d8c4> >>>>> . >>>>> >>>>> Here are all the variations of the *syntax*: >>>>> >>>>> import List >>>>> import List exposing (map, filter) >>>>> import List exposing (..) >>>>> >>>>> import List as L >>>>> import List as L exposing (map, filter) >>>>> import List as L exposing (..) >>>>> >>>>> The most important change is in *semantics* though. In cases 1-3 you >>>>> are able to refer to anything in the List module as List.member and >>>>> List.isEmpty. So importing a module implies that you want to be able >>>>> to use it's name to qualify all of its values. >>>>> >>>>> In cases 4-6, it is the same except you can qualify with L but not >>>>> List. Why hide List though? There may come a time when you don't want >>>>> name overlaps with modules, so this makes it possible to avoid collisions. >>>>> >>>>> Overall, I think this meets my goals for this change: >>>>> >>>>> - All imports are explicit and easy to find. No one can introduce >>>>> a dependency on line 1500 of a file. >>>>> - There will be less duplication in the import section. No >>>>> importing the same thing twice in different ways. >>>>> - It will be easier to understand for beginners. >>>>> - It somewhat discourages exposing by making it longer. >>>>> >>>>> *Remaining Questions:* >>>>> *1) *What happens when there are multiple imports of the same module? >>>>> >>>>> - *a)* Sean proposed making everything additive >>>>> <https://github.com/elm-lang/elm-compiler/issues/874>. This would >>>>> make hiding any defaults impossible. >>>>> - *b)* Maybe we can just disallow multiple imports of the same >>>>> module? >>>>> >>>>> *2)* How this should interact with the current default imports >>>>> <https://github.com/elm-lang/core#default-imports>? >>>>> >>>>> - *a)* Anyone can refer to Basics, List, Maybe, Result, and Signal >>>>> from anywhere? Seems weird. >>>>> - *b)* Certain values are exposed, but the modules are not >>>>> available for making things qualified. >>>>> >>>>> It seems like 1.b and 2.a fit together best. We could make it so >>>>> user-defined imports always override default imports and there are no >>>>> duplicate user-defined imports. >>>>> >>>>> But maybe there are other alternatives? >>>>> >>>> -- >>>> 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.
