Eliminated usages of "field" in the spec.

Eliminated usages of "field" in the spec.

It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.

Fixes #24333.

BUG=
R=lrn@google.com

Committed: https://github.com/dart-lang/sdk/commit/473f2c9a60fb7194cd9e558faf32b3fa51da57f6

[eernst, 2017-01-06 18:18:30]

eernst@google.com changed reviewers:
+ lrn@google.com

[eernst, 2017-01-06 18:18:30]

A small fix to the spec, eliminating the ambiguity around 'field' and resolving
#24333.

[eernst, 2017-01-06 18:42:30]

Description was changed from

==========
Eliminated usages of "field" in the spec.

It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.

Fixes #24333.
==========

to

==========
Eliminated usages of "field" in the spec.

It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.

Fixes #24333.

BUG=
==========

[Lasse Reichstein Nielsen, 2017-01-09 08:55:12]

lgtm

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:199: It is therefore impossible, e.g., to define
a class that declares a method and an instance variable with the same name in
Dart.
It doesn't have to be an instance variable - the existing text also covered a
"static variable", just as method covers both static and instance methods. So:
"(static or instance) variable". Or really, just "getter" - because instance
variables don't have names, their implicit getters do.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1063: This implies that a getter can never
override a method, and a method can never override a getter or an instance
variable.
It's really not necessary to mention instance variables here - instance
variables/fields are anonymous, they just introduce an implicit getter with that
name, and we already mentioned getters.
(But, since it's commentary, it is allowed to repeat itself for pedagogical
reasons).

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1430: Then, the instance variable $v$ of $i$ is
bound to $o$, unless $v$ is a final variable that has already been initialized,
in which case a runtime error occurs.
This is statically detectable, so in Strong Mode we should ensure that it's a
compile-time error (if we don't already).

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1842: Then $m$ overrides $m^\prime$ if $m^\prime$
is not already overridden by a member of at least one of $S_1 \ldots S_{j-1}$
and neither $m$ nor $m^\prime$ are instance variables.
We are still being inconsistent. Fields are not really *members*. They are
*member declarations* and they introduce /getter/ and (potentially) /setter/
*members*.

That's why we get paragraphs like this that have to say that you override unless
one of them is an instance variable - but doesn't mention that the implicit
getter/setter does override (leaving that for the commentary below).
Maybe we can find a way to do the distinction properly (but that's for another
CL).

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1875: When we speak of members here, we mean
accessible instance or static variables, getters, setters, and methods
(\ref{classes}).
Yep, inconsistent! We do "member lookup" elsewhere and won't find variables
because they are not really members.
Again, OK for now, should fix later.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:2479: \item $c_1$ and $c_2$ are constant objects
of the same class $C$ and each instance variable of $c_1$ is identical to the
corresponding instance variable of $c_2$. OR
... and the value of each instance variable of ... is identical to the value of
the corresponding instance variable ... 

(an "instance variable" is not an object, it's value is).

[eernst, 2017-01-09 10:16:53]

Review response.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:199: It is therefore impossible, e.g., to define
a class that declares a method and an instance variable with the same name in
Dart.
On 2017/01/09 08:55:12, Lasse Reichstein Nielsen wrote:
> It doesn't have to be an instance variable - the existing text also covered a
> "static variable", just as method covers both static and instance methods. So:
> "(static or instance) variable". Or really, just "getter" - because instance
> variables don't have names, their implicit getters do.

Actually, my reasoning was "it says `e.g.`, so we just need an example that
works, not a complete list".

I adjusted it to getter anyway, because that's just as good as an example, it
covers the inst/stat variables, we avoid the heavy 'instance or static' (I think
a bare `variable` will be too confusing to use it as `instance or static
variable`), and the reference to variables is present in the next sentence
anyway.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1063: This implies that a getter can never
override a method, and a method can never override a getter or an instance
variable.
On 2017/01/09 08:55:12, Lasse Reichstein Nielsen wrote:
> It's really not necessary to mention instance variables here - instance
> variables/fields are anonymous, they just introduce an implicit getter with
that
> name, and we already mentioned getters.
> (But, since it's commentary, it is allowed to repeat itself for pedagogical
> reasons).

Right. I'll keep it to give the hint to readers who don't automatically see the
connection.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1430: Then, the instance variable $v$ of $i$ is
bound to $o$, unless $v$ is a final variable that has already been initialized,
in which case a runtime error occurs.
On 2017/01/09 08:55:12, Lasse Reichstein Nielsen wrote:
> This is statically detectable, so in Strong Mode we should ensure that it's a
> compile-time error (if we don't already).

Agreed: We should be able to detect statically precisely when that will occur.

I added a comment "%%STRONG_MODE: ..". We could use that to put in reminders
about locations where strong mode (or 2.0) requires updates.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1842: Then $m$ overrides $m^\prime$ if $m^\prime$
is not already overridden by a member of at least one of $S_1 \ldots S_{j-1}$
and neither $m$ nor $m^\prime$ are instance variables.
On 2017/01/09 08:55:11, Lasse Reichstein Nielsen wrote:
> We are still being inconsistent. Fields are not really *members*. They are
> *member declarations* and they introduce /getter/ and (potentially) /setter/
> *members*.
> 
> That's why we get paragraphs like this that have to say that you override
unless
> one of them is an instance variable - but doesn't mention that the implicit
> getter/setter does override (leaving that for the commentary below).
> Maybe we can find a way to do the distinction properly (but that's for another
> CL).

Acknowledged.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:1875: When we speak of members here, we mean
accessible instance or static variables, getters, setters, and methods
(\ref{classes}).
On 2017/01/09 08:55:12, Lasse Reichstein Nielsen wrote:
> Yep, inconsistent! We do "member lookup" elsewhere and won't find variables
> because they are not really members.
> Again, OK for now, should fix later.

Acknowledged.

https://codereview.chromium.org/2613293002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:2479: \item $c_1$ and $c_2$ are constant objects
of the same class $C$ and each instance variable of $c_1$ is identical to the
corresponding instance variable of $c_2$. OR
On 2017/01/09 08:55:12, Lasse Reichstein Nielsen wrote:
> ... and the value of each instance variable of ... is identical to the value
of
> the corresponding instance variable ... 
> 
> (an "instance variable" is not an object, it's value is).

Indeed, done!

[eernst, 2017-01-09 10:29:39]

Description was changed from

==========
Eliminated usages of "field" in the spec.

It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.

Fixes #24333.

BUG=
==========

to

==========
Eliminated usages of "field" in the spec.

It turned out to be "instance variable" or "static or instance
variable" in all cases. I considered writing "member variable" for the
latter, but we would then need to introduce that phrase somewhere, and
maybe refer to it at each usage, which would be more verbose.

Fixes #24333.

BUG=
R=lrn@google.com

Committed:
https://github.com/dart-lang/sdk/commit/473f2c9a60fb7194cd9e558faf32b3fa51da57f6
==========

[eernst, 2017-01-09 10:29:41]

Committed patchset #1 (id:1) manually as
473f2c9a60fb7194cd9e558faf32b3fa51da57f6 (presubmit successful).