Daniel Gibson wrote:
Stanislav Blinov schrieb:
spir wrote:
Hello,
I think the compiler should complain when sub-classes hold fields
with the same name as super-classes. After all, names (in addition to
types) are used to identify. Intentionally reusing the same name
would not only be bad design, but open the door to hidden bugs.
This issue has been brought up several times before. I myself see no
harm in this shadowing, though making a compiler issue a warning
when shadowing *public* fields occurs would be a good thing.
Shadowing non-public fields, in my opinion, is harmless, and
preventing it would actually narrow down name choice with each
subsequent subclassing.
No, only shadowing private fields is harmless (because the sub-class
can't access them anyway), but shadowing protected fields is about as
bad as shadowing public fields.
Well, yes. Even shadowing of private fields is as bad as long as a
subclass is in the same module as base class. Come to think of it,
maybe, it'd be better if the compiler warned about shadowing whenever
shadowed name is directly visible, not just in case of public fields.
Though the problem fully manifests itself in client code, where only
public members are exposed.
The other option that comes to mind is simply disallow public fields
for classes. This may sound too strict, but I think that public fields
is something that's not as usable for classes as for structs.
Disallowing public fields is too restrictive IMHO.
Maybe. I just always view public fields as encapsulation breakers. And
silent invariant breakers. And maintenance cripplers :)
