You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avoid referring to a private field of a class outside the class declaration.
Can be fixed by making the field public, making the class private, making the enclosing reference private, adding the base/sealed/final modifier, or moving the reference into the class declaration.
Kind: AVOID
Currently, the following produces zero static analysis warnings:
interfaceclassA {
finalint _value =0;
}
intgetValue(A a) => a._value; // always throws an error
And when combined with an abstract_private_class_member violation, it doesn't matter whether the class is extended or implemented:
abstractclassA {
intget _value;
}
intgetValue(A a) => a._value; // always throws an error
Examples
classA {
finalint _value =0;
}
// BADintgetValue(A a) => a._value;
classB {
// BADfactoryB.fromA(A a) =>B(a._value);
}
// GOOD, class is privateclass_A {
finalint _value =0;
}
// GOOD, enclosing function is privateint_getValue(A a) => a._value;
// GOOD, field is publicclassA {
finalint value =0;
}
// GOOD, class has the "base" modifierbaseclassA {
finalint _value =0;
}
// GOOD, private field is accessed within the classclassA {
finalint _value =0;
intget value => _value;
}
Discussion
There probably wouldn't be a "quick-fix" for the rule, since there are many solutions (some of which may cause a name overlap).
Probably low-priority
If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.
I've never seen a real-world situation where this rule has been broken.
The text was updated successfully, but these errors were encountered:
Description
Avoid referring to a private field of a class outside the class declaration.
Can be fixed by making the field public, making the class private, making the enclosing reference private, adding the
base
/sealed
/final
modifier, or moving the reference into the class declaration.Kind: AVOID
Currently, the following produces zero static analysis warnings:
And when combined with an
abstract_private_class_member
violation, it doesn't matter whether the class is extended or implemented:Examples
Discussion
There probably wouldn't be a "quick-fix" for the rule, since there are many solutions (some of which may cause a name overlap).
Probably low-priority
I've never seen a real-world situation where this rule has been broken.
The text was updated successfully, but these errors were encountered: