Has anyone watched Avdi's episode on barewords? https://www.rubytapas.com/2012/10/01/episode-004-barewords/ (I haven't checked whether this one is free or requires a subscription.) The concept seems to apply to what Dave was requesting.
On Mon, Dec 5, 2016 at 11:09 AM Amos King <[email protected]> wrote: > Is this something that could be solved with an external tool added to your > build chain? > > Amos King > Binary Noggin > > > On Dec 5, 2016, at 09:29, Allen Madsen <[email protected]> wrote: > > > > I would also argue for case 3. > > > >> However, it does not solve the contextual overhead, When changing or > reading code, I still need to carefully look at the surrounding context to > see if the variable is not being used in order to avoid the warning (or I > can write the code and wait for the compiler to tell me). > > > > I'm not sure why I would worry much about it if the compiler is going > > to tell me about. The whole point of the compiler warning you is so > > that you don't have to think about and still end up with something > > correct. > > > >> But to make things worse, the suggestion of only warning if there is a > function, means that by simply adding a function into a given module, you > may now get warnings on other functions in that same module, simply because > you defined a new function 100LOC below. It is even worse if you consider > imports: if you are importing or using an external library and it adds a > new function to its API, you may have warnings when updating your > dependency. > > > > The reason this feels unconvincing to me is because the situations > > where this comes up would be very infrequent for me. It's possible a > > module I import will define a function with zero arity that shadows a > > variable that I define. However, the chance of that seems very small. > > A more likely, scenario is that I define a function with zero arity > > within a module and also use the same name for a variable. For me, > > that would also be particularly unlikely though. The case where I > > define zero arity functions that don't have conflicting local > > variables is very high though. So, allowing zero arity functions > > without parens optimizes for my most common use case. > > > > In the situation where there is a conflict, I need effective tools to > > find the issue. An underlying assumption I had was that when the > > warning was detected, it would tell me the locations of the conflict. > > In the case of the 100LOC below conflict, the distance doesn't really > > matter because the warning told me on line 1 I have a variable that > > conflicts with a method defined on line 100. In the case of the method > > coming from a module import, I would expect it to tell me what import > > included the method that is causing the conflict. > > > > Allen Madsen > > http://www.allenmadsen.com > > > > > >> On Mon, Dec 5, 2016 at 9:25 AM, Ólafur Arason <[email protected]> > wrote: > >> I don't have horse in the race, I'm fine with either 2 or 3. But like > with > >> def, defmodule, @attributes and other uses of non parenthesis function > >> calls, there are nice uses of non parenthesis in zero arity functions. > But > >> like you have stated there are some really bad problem that can arise > and > >> it makes the code unclear sometimes. I only proposed option 3 because it > >> would cover most of the problems with the dual use of names. But I also > >> do realize that it's harder to implement and might not be a perfect > >> solution. > >> > >> It's like reusing variable name, it's not necessary, it causes some > problems > >> but > >> it's sometimes better than: > >> green = green() > >> > >> Regards, > >> Olaf > >> > >>> On Monday, 5 December 2016 07:16:33 UTC-5, José Valim wrote: > >>> > >>> To further clarify the previous response, we have three options: > >>> > >>> 1. Do not warn if a variable is used as a function call (Elixir v1.3) > >>> > >>> 2. Warn if a variable is used as a function call (Elixir v1.4) > >>> > >>> 3. Warn if there is a variable and a function with the same name > (proposed > >>> in this thread) > >>> > >>> The response above was about option 3. I consider it to be the worst > >>> option because it solves less than half of the problems the warning was > >>> meant to solve while having introducing drawbacks that do not exist in > >>> options 1 and 2. > >>> > >>> So if you believe 3 is still the way to go, please *elaborate on the > >>> points on why it is a good reason* and why you agree or disagree with > the > >>> drawbacks previously explained. > >>> > >>> José Valim > >>> www.plataformatec.com.br > >>> Skype: jv.ptec > >>> Founder and Director of R&D > >>> > >>> On Mon, Dec 5, 2016 at 1:06 PM, José Valim < > [email protected]> > >>> wrote: > >>>> > >>>>> I think that if you have introduced a var anywhere in your module > that > >>>>> has the same name as a zero arity function then this warning should > be shown > >>>>> that solves all the problems that have been stated. > >>>> > >>>> I have explained in a previous reply why this is harmful and why it > does > >>>> not solve all the problems stated. The warning will not only show up > when > >>>> you introduce a variable, but also when you introduce a new function > in the > >>>> module and that will trigger warnings in unrelated part of the code. > >>>> > >>>> While having the discussion is important, it is also important to move > >>>> the discussion forward. This is the third or fourth time that "emit a > >>>> warning only if there is a variable and a function" is proposed after > it was > >>>> already explained why such is considered harmful. This means either > 1. the > >>>> previous reply was not read, which is frustrating because it puts me > in the > >>>> position of repeating the same points over and over again, or 2. the > >>>> previous reply was read but folks don't agree with its conclusions. > If the > >>>> latter, nobody is explaining *what they don't agree with*, which does > not > >>>> allow the conversation to move forward. > >>>> > >>>> I will copy the reply on why warning only if there is a function is a > bad > >>>> idea one last time: > >>>> > >>>>> So going back to the cases the current warning is meant to solve > that I > >>>>> sent in an earlier email, warning only if it shadows a function, > does not > >>>>> solve the first case although it does also solve the second case. > >>>> > >>>>> However, it does not solve the contextual overhead, When changing or > >>>>> reading code, I still need to carefully look at the surrounding > context to > >>>>> see if the variable is not being used in order to avoid the warning > (or I > >>>>> can write the code and wait for the compiler to tell me). > >>>> > >>>>> But to make things worse, the suggestion of only warning if there is > a > >>>>> function, means that by simply adding a function into a given > module, you > >>>>> may now get warnings on other functions in that same module, simply > because > >>>>> you defined a new function 100LOC below. It is even worse if you > consider > >>>>> imports: if you are importing or using an external library and it > adds a new > >>>>> function to its API, you may have warnings when updating your > dependency. > >>>> > >>>>> Those are really undesired consequences. I believe we should either > >>>>> define that one of them has higher precedence (Elixir v1.3) or make > sure > >>>>> they don't conflict (Elixir v1.4). > >>>> > >>>> I would love to continue the discussion but if it ultimately ends up > with > >>>> me repeating previous points, it will eventually lose interest. > >>>> > >>>> > >>>> José Valim > >>>> www.plataformatec.com.br > >>>> Skype: jv.ptec > >>>> Founder and Director of R&D > >>>> > >>>>> On Mon, Dec 5, 2016 at 11:57 AM, Ólafur Arason <[email protected]> > wrote: > >>>>> > >>>>> I think that if you have introduced a var anywhere in your module > that > >>>>> has the same name as a zero arity function then this warning should > be shown > >>>>> that solves all the problems that have been stated. > >>>>> > >>>>> We compile our code with warnings as errors so it's very important > for > >>>>> us to have warnings that point out problems in our code. > >>>>> > >>>>> I feel like the sentiment about being able to use zero arity function > >>>>> without parentheses is pretty split in this thread. If there was a > consensus > >>>>> about this warning I would be fine with it. > >>>>> > >>>>> Regards, > >>>>> Olaf > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "elixir-lang-core" group. > >>>>> To unsubscribe from this group and stop receiving emails from it, > send > >>>>> an email to [email protected]. > >>>>> To view this discussion on the web visit > >>>>> > https://groups.google.com/d/msgid/elixir-lang-core/874996b8-6759-4a77-be31-d7e050cd6123%40googlegroups.com > . > >>>>> For more options, visit https://groups.google.com/d/optout. > >>>> > >>>> > >>> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "elixir-lang-core" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/elixir-lang-core/a9fd5f51-f302-49ff-b228-04ff2ff248bd%40googlegroups.com > . > >> > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "elixir-lang-core" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CtFSjWZUeXp9djKhc97xykaObc6F39BE4PLQTQjQSaFuw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/6DC06C31-5933-4980-A9B3-69C83276A4C8%40binarynoggin.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAA1yQx8j8OYV1pSVLQU4vXZBMOE1pxtPnY-_gmb72ds2W98TBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
