But it would cause naming collisions if there were two imported modules
both with id. As import exposing (a, b) would break the guarantee against
the problem I had, that could be made clear, perhaps by naming it unsafe
import exposing (a, b).
On Saturday, August 20, 2016 at 9:07:44 AM UTC+1, Will White wrote:
>
> Yes, you're right. What I should have said is that it shouldn't be
> something the programmer has to think about *until* there's a name
> collision.
>
> I've been import exposing (..) a lot, and using variable names like id
> too. I haven't noticed lots of naming collisions as you describe, so I
> thought I'd check it out:
>
> module Main exposing (..)
>
> import Html exposing (..)
> import Html.Attributes exposing (..)
> import Html.App exposing (..)
>
> main =
> Html.App.beginnerProgram
> { model = ()
> , update = (\_ _ -> ())
> , view = view
> }
>
> id =
> 2
>
> view model =
> div [ class "something" ] []
>
>
> This doesn't actually cause any naming collisions between id and
> Html.Attributes.id.
>
> On Friday, August 19, 2016 at 11:29:37 PM UTC+1, Nick H wrote:
>>
>> 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...@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...@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...@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.
