Add syntax to support object protected inheritance

[DartBot]

This issue was originally filed by le...@google.com

---

From discussion thread: https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/6fd72014c119934d/6bed87932b58b762?lnk=raot#­6bed87932b58b762

Some variant of protected inheritance would be useful, and a protected by object sort of inheritance would likely be better than protected by class, because class based protection leads to any subclass being able to mess with any other subclass in unexpected ways. Because object protected methods could be statically bound, there is no need to require a prefix to identify them, so the concept could be orthogonal to library privacy. Here is a proposed syntax:

class c {
  // This is publicly visible
  var publicFunc() {}

  // This can be accessed by any code in this library
  var _privateFunc() {}

  // This can only be invoked on this
  var this.protectedFunc() {}

  // This can only be invoked on this by code in this library
  var this._privateProtectedFunc() {}
}

[kasperl]

Added Area-Language, Triaged labels.

[gbracha]

Set owner to @gbracha.
Added this to the Later milestone.
Added Accepted label.

[DartBot]

This comment was originally written by le...@google.com

---

It occurs to me that this gets more interesting when you consider properties, because you can have different levels of protection on the getter and setter without giving them different names if you use object protection. In C# it is common to declare properties "public int Foo { get; private set; }" as this is what you want 90% of the time; a value that can be read by anyone but can only be set by the class. Dart doesn't have a short syntax like this, but a keyword akin to final on a field that makes it readable by any object but only writeable on this would be just as good for this case, and this covers a very large fraction of the use of properties.

[DartBot]

This comment was originally written by off...@mikemitterer.at

---

The lacking of a way to protect functions from outside usage leads to more public functions and this could not be in the sense of small class interfaces...

The use of Mixins oder the Strategy-Pattern doesn't solve the problem either.

Sample:
abstract class Mixin1 {
  String _objectToString() => "Robin";
}

class JsonTestA implements Mixin1 {
  String getName() => _objectToString();
  
  String _objectToString() => "Batman";
}

class JsonTestB extends JsonTestA with Mixin1 {
  String getName() => _objectToString();
}

testMixins() {
  final Logger logger = new Logger("test.testMixins");
  
  group('Mixins', () {

    test(' -> generate', () {
      final JsonTestA jt = new JsonTestB();

      // True if Mixin1 is in the same library, but if not, the test fails!
      expect(jt.getName(),"Robin");
      });
   });
}

There is no way to define a Template with private functions in a library and keep those function protected or private in subclasses defined in another library.

[DartBot]

This comment was originally written by nbil...@gmail.com

---

I'm sure the Dart engineers have thought about this heavily, but I did want to chime in that there are a growing number of workarounds in the Dart codebase due to lack of the protected namespace.

Examples:
ChangeNotifier observed(), unobserved() -- made public so they are overridable, which doesn't make sense to the consumer of the ChangeNotifier API.

ObservableList _recordChange -- private, requiring any subclass of ObservableList to copy several methods to use that functionality.

I feel that the lack of protected makes the developer choose between either allowing their code to be extensible or keeping their public API clean.

[kevmoo]

I pondered doing this as an annotation. See https://code.google.com/p/dart/issues/detail?id=6119

Zero effect on runtime behavior. It'd basically act like @­deprecated.

The editor/analyzer would show warnings if used outside of the class hierarchy.

We get most of the benefits desired without having to make the type system more complicated.

[DartBot]

This comment was originally written by le...@google.com

---

Kevin, your proposal seems geared toward class-based protection, whereas this bug is related to object-based protection. While class-based protection is the more common form, I'm not aware of any use cases of it that wouldn't fit the object-based model better. The other reason to go with it is because it doesn't rely on the type system to determine visibility, it can be implemented fully in dart, whereas with class-based you'd want a more limited implementation like your annotation proposal.

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[DartBot]

This comment was originally written by le...@google.com

---

New thread on this: https://groups.google.com/a/dartlang.org/d/topic/misc/cvjjgrwIHbU/discussion

Lasse suggested a name-based approach, and while it's not necessary to go that route it would be very easy to implement that way. So for example, if we make all protected functions prefixed by "**", then all the compiler has to do is 1.) Do not mangle ** names at all, the way it does for _ names, and 2.) Forbid any calls to a __ member of any object other than this. No static analysis necessary.

This variant has the potential feature that it would allow classes to call protected methods defined in subclasses. Or this could be prevented with some straightforward static analysis.

Also, no one will accidentally override a protected method with a public method.

[DartBot]

This comment was originally written by le...@google.com

---

It occurs to me that you could support a combination of 1) object protected and 2) static class protected easily, and they could be used in combination as a way of doing class protected inheritence. It would be a little convoluted, but I don't know that it's a common use case anyway. So for example:

// library A:

class BaseClass {
  void __protectedFunc() {}

  void _callProtectedFunc() => __protectedFunc(); // legal, calling protected func on this.
  // exposes __protectedFunc to all subclasses even when not invoking on this
  static void __callProtectedFunc(BaseClass other) {
    // other.__protectedFunc() // compiler error; protected member functions can only be invoked on this.
    other._callProtectedFunc(); // legal, library private call.
  }
}

// library B:

class SubClass extends BaseClass {
  void doSomethingWith(BaseClass other) {
     __protectedFunc() // legal, invoked on this
    // other.__protectedFunc() // compiler error; protected member functions can only be invoked on this
    // other._callProtectedFunc() // runtime error/compile-time warning; cannot call library private method
    BaseClass.__callProtectedFunc(other) // okay, SubClass inherits from BaseClass
  }
}

class Unrelated {
  void func(BaseClass other) {
    // BaseClass.__callProtectedFunc(other) // compiler error; Unrelated does not inherit from BaseClass.
  }
}

[DartBot]

This comment was originally written by @Emasoft

---

Dart needs protected members. The very useful "protected" keyword is sorely missing. Currently many people are using workarounds to reproduce the protected state. For example here is a method to do it:

library view;

abstract class View {
  factory View({HtmlElement host}) = ViewImpl;

  void activate() {
  }
}

abstract class ViewImpl implements View {
  ViewImpl({this.host});

  @­override
  void enable() {
    host.classes.remove('disabled');
  }
}

....In another library you write:

library button; // notice, this is another library

abstract class Button extends View {
  factory Button({String title, HtmlElement host}) = ButtonImpl; // The magic happens here!
}

class ButtonImpl extends ViewImpl implements Button {
  String title; // voila, a protected property

  ButtonImpl({this.title, HtmlElement host}) : super(host: host);
}

....and you can use it like this:

final button = new Button(title: "Cancel", host: element);

button.title // => cannot access!

....moreover, you can access the protected field in e.g. a unit test:

// Instantiate the *Impl class to side-step the protection.
final button = new ButtonImpl(title: "Cancel", host: element);
expect(button.title, equals("Cancel"); // => it works!

In short, you hide your 'protected' methods in Impl classes. You can freely extend the implementation in different libraries.

Source: http://stackoverflow.com/a/28513391/959398

Those workarounds are spreading and making the Dart code of many libraries unreadable and messy. Please add the "protected" keyword to the standard Dart syntax specifications.

Thanks.

[DartBot]

This comment was originally written by @zoechi

---

Doesn't need to be a keyword. An annotation @­protected like @­override would be enough. And it wouldn't require a language change at all. The analyzer complaining about violation of protected access and IDE's not listing them in autocompletion when not appropriate would be enough.

[DartBot]

This comment was originally written by @Emasoft

---

Ok, but please do it quickly. Those workarounds are spreading and making the Dart code of many libraries unreadable and messy.