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.
