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.
