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.eremo...@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.wh...@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+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. > -- 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.
