Let me try to state my concern in a different way. You say: 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 >
I completely agree with this! And it is exactly why I write "exposing (class)" and not "exposing (..)". Because I am telling the compiler "Whatever else is in Html.Attributes, I don't want to think about it. So please leave it in its namespace where it won't get in my way." This approach works whether class is the only function in the module, or if it is one of millions. On Fri, Aug 19, 2016 at 2:23 PM, Nick H <falling.maso...@gmail.com> wrote: > 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 <will.n.wh...@gmail.com> > 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 <joey.e...@gmail.com> >>> 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 <will.n...@gmail.com> >>>> 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 elm-discuss...@googlegroups.com. >>>>> 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 elm-discuss...@googlegroups.com. >>>> 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 elm-discuss+unsubscr...@googlegroups.com. >> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
