> Basically, what compelling problem drove this change? It isn't an issue I
ever had before, and the change seems to make my code worse.
There were a couple scenarios that I either personally ran into or were
frequently reported. One of those came from Plug test suite. In Plug it is
common to pass the connection named as "conn" around between setup/tests:
setup do
{:ok, conn: conn(:get, "/foo/bar")}
end
test "can do a get request" do
assert SomePlug.call(conn, []).path_into == ["foo", "bar"]
end
There is a bug in the code above in that we should be extracting the "conn:
conn" variable out of the context but I forgot to. However, since Plug.Test
defines a conn/0 function, a connection would be created automatically on
the SomePlug.call(conn, []) call but without the HTTP method and path I
have set in setup. This usually leads to very frustrating debugging
sessions because the error above is not obvious. You will very likely first
debug SomePlug.call, then figure out the path was never set to "/foo/bar",
which only then will lead you to the root cause.
The opposite also happens. For example I may start a property testing like
this:
int = 42
ptest list: list(length: int, of: atom) do
assert ...
end
Then later I come back to the code, decide that my list can be made of
atoms and ints, and rewrite it as follows:
ptest list: list(length: int, of: choose(atom, int)) do
assert ...
end
which will now fail due to the previous int = 42 line.
A lot of it boils down to how much of the surrounding scope you need to
parse in order to do a change to the codebase. Having variables
automatically upgrading to function calls means that, if you ever want to
call a zero-function arity without parens, you need to check all variables
being defined.
While some may have never experienced this issue, it has affected many
other developers, including myself, and I would have appreciated more help
from the compiler.
It is very similar to the deprecation we did on Elixir v1.2 (or v1.3) about
imperative assignment. While there was no ambiguity in imperative
assignment, the fact the feature existed meant that in order to understand
the value of a variable at certain piece of code, I had to traverse all
nested expressions in the chance a variable was defined inside an if that
was inside a case.
By forbidding such constructs, we need to keep less context in our brain
when reading or changing the code. And it is important to understand this
ability changes from person to person. For instance, some developers are
very comfortable with "import Foo" while others do not appreciate it as it
means you need to have an understand of everything Foo brings into the
current scope.
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Sat, Dec 3, 2016 at 4:36 AM, Dave Thomas <[email protected]> wrote:
> I've been living with 1.4 for a few weeks now.
>
> I am bugged by the new warning:
>
> ~~~
> warning: variable "int" does not exist and is being expanded to "int()",
> please use parentheses to
> remove the ambiguity or change the variable name
>
> test/generators/int_test.exs:10
> ~~~
>
> Partly it is because it makes my code a lot uglier. For example, in
> quixir, instead of
>
> ~~~elixir
> test "two plain types" do
> ptest a: int, b: list do
> assert is_integer(a)
> assert is_list(b)
> end
> end
> ~~~
>
> I now have to write:
> ~~~ elixir
> test "two plain types" do
> ptest a: int(), b: list() do
> assert is_integer(a)
> assert is_list(b)
> end
> end
> ~~~
>
> Ugh.
>
> Even worse, the premise of the warning seems wrong. It assumes `int` is a
> variable, which doesn't exist. But it _does_ know that `int` is a function,
> because if I misspell it and put ()s on, I get a compilation error. So why
> can't it just do that: is a bare name is encountered that isn't a variable,
> just internally tack on the ()s are see what happens. Which I think is the
> old way.
>
> Basically, what compelling problem drove this change? It isn't an issue I
> ever had before, and the change seems to make my code worse.
>
>
> Dave
>
> --
> 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/924b70db-79f1-43c1-afc7-
> 49a94cd541e5%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/924b70db-79f1-43c1-afc7-49a94cd541e5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAGnRm4JX0PJ8XJeD6eLm8-2dt9-kyh3b_u2%2BwU6vQ_vfNtu01g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
