Add a protected keyword for real protected access (instead of the @protected annotation)

[magicleon94]

Hi,
it would be great to have the capability of a real protected keyword to manage the visibility of class attributes.

By real, I mean by not using the @protected annotation. Something like this:

// file offset_adder.dart
abstract class  OffsetAdder {
  protected int getAdditionValue();
  int addOffsetTo(int x){
    return x + getAdditionalValue();
  }
}

// file random_adder.dart
class RandomAdder extends OffsetAdder{
  @override
  protected int getAdditionValue(){
    return Random().nextInt();
  }
}


void main(){
  final adder = RandomAdder();
  final base = 10;
  final result = adder.addOffsetTo(base);

  //but this won't be even visible and will produce a linting and compile time ERROR 
  //and not a warning
  final offset = adder.getAdditionValue();
}

The reason I'm asking this is that when we mark something with the @protected annotation, it will only be a listing warning, since methods or properties marked with the @protected annotation will be publicly visible and nothing will stop anyone from using those methods or properties, they'll just have to ignore the linting rule.

When marking something as protected I expect it to be visible only to a class and its subclasses, and I'm probably willing to avoid making protected stuff visible to anyone, both for "privacy" and, mostly, to avoid clutter when leveraging the autocomplete feature of the IDE.

As of today, I've found only two ways to have a behaviour similar to a real protected keyword.

The first one is make the stuff you would like to make protected as private and define all the subclasses within the same file (turns out that the Dart private concept has scope in the file and not in the class, it'd be great to have a real private thing too, but that's not the scope of this request): subclasses will see the "private" things and will be able to use them.

Another one is using again the "private" as protected trick mentioned above, but instead of having all in one file (which might result in a mess), we could use the part/part of directives, which, in the end, is a way to have multiple files treated as one.

Is a real protected feature possibile?

If not, let me ask this: I'm sure you have thought of that when designing the language, why have you dropped the idea of a protected concept?

[rrousselGit]

Random guess, I could be wrong: Because there's no impact on the runtime behavior

Private variables have to be part of the language because there is a behavior change. Two interfaces can declare a private member with the same name, without causing name conflict:

// a.dart
mixin A {
  int _value = 42;
  void printA() => print('$_value');
}

// b.dart
mixin B {
  int _value = 21;
  void printB() => print('$_value');
}

// main.dart

import 'a.dart';
import 'b.dart';

class Impl with A, B {}

void main() {
  final value = Impl();
  value.printA(); // 42
  value.printB(); // 21
}

But with a protected, this behavior change doesn't exist.

As such a lint implements 100% of the feature, and similarly to @deprecated, making @protected part of the language doesn't bring any extra.

The fact that people can ignore the warning does not change the fact that there is a warning and that the maintainer of code can change the behavior of that protected variable safely.
If people ignored the warning and their code broke, it is their fault.

Maybe we should simply have the IDE hide the @protected variables?

[magicleon94]

Well, I agree with the behaviour you've illustrated with mixin but I think that's a different case, since that is more a composition behaviour than the inheritance stuff I had in mind.

Maybe we should simply have the IDE hide the @protected variables?

This might be good too. And probably will require a lot of less effort to implement.

Either a keyword or a real behaviour for the notation produces the same output I'm proposing.

[lrhn]

Duplicate of #835. See also #757.