As i said earlier, it does not work because fields and local variables
have different semantics,
fields are initialized with a default value while local variables need
to be initialized before use.
So the curtain is just a veil that will be pierced by any students
moving declarations around.
Of course it "works", it just might not work how you would prefer it to.
Prior to learning about fields, the user can perceive local variables
(declared in a method) and "shared" variables (accessible to all members
of the class.) They can learn about their characteristics. Then, when
they learn about classes and fields and accessibility, they can learn
that the variables they were calling "shared" are really fields. The
distinction between locals and fields is there from the beginning,
though for most use cases, they will not notice the difference. When
they're ready to learn the fine differences, there's not anything to
unlearn.
From my personal experience, unifying local variable and field leads
to more pain than gain, mostly because local
Who said anything about unification of fields and locals? Where did you
get such an idea that this is what is being proposed?
First students will learn about statements. Then they will probably
learn about local variables. They can be taught that they disappear
when the method exits, and each invocation of the method gets a fresh
copy. Then they can learn about multiple methods, and then that there
are variables that can be shared across methods and retain their values
across method invocations, and while their declaration syntax is the
same (they're both variables, after all), the _place_ in which they are
declared is different (which is what makes them shared), and shared
variables have slightly different characteristics (though not so
different they have to learn this immediately). They can learn the
characteristics of shared variables when it makes sense to teach this.
And when the curtain is pulled back, they learn all fields have the
characteristics of these shared variables.
