dup field in sub-class should be reported by the compiler

[sa]

== Quote from sa (someanon at yahoo.com)'s article
> > Exactly what problem does this solve? If you're writing a derived class,
> > and you create another field of the same name as a field in the base
> > class, what bug has been created? The base class functions will still
> > use the base class field, the derived class functions will still use the
> > derived class field. The fields aren't polymorphic, so no hijacking can
> > happen.
> > I just don't see the issue.
> It's less a problem if the programmer is *aware* of the re-definition; but in
> practice, most the time, the programmer just forget, and will *assume* there's
> only one definition, then it will cause strange error in his eye.
> Now, even from an OO modelling point of view:
> Dog {
>   Tail tail;
> }
> MyDog {
>   Tail tail;
> }
> Why should MyDog have a tail which is already defined in Dog?
> It burden the programmer's thoughts, instead of simplify it.

Or during code refactoring, the programmer moved the field to the parent class,
but forget to delete it in the sub class.

The language should be defined to make it harder for the programmer to run into
such error.  So at least it should warn the user.