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.
