Google Dart visibility of methods and properties

Question

Just to avoid some misunderstanding, I know that Google Dart handles things on a library level and that private properties and methods can be identified with a underscore prefix.

Is this still up to date as of 2017? Are there any plans for adding object level visibility keywords like: private, protected or public?

I dont just want to do something random but im rather interested in best practices. The way I see it is: if I dont want class one to see what class two has then both must be in different libraries, those libraries then are part of a bigger package.

libraries = privacy between classes packages = privacy between files

What about fine grained control of privacy? I mean maybe there is 1 thing I want private. What about using visibility when using inheritance? I mean protected keywords can be really valuable.

Here a little example in one file:

class one {
  int n = 1;

  one() {
    var test = new two(n);
    print(test.showNumber());
  }
}

class two {
  int n = 2;

  two(n) {
    this.n += n;
  }

  int showNumber() {
    return n;
  }
}

As it stands now, both classes can do what they want.

Answer 1

Dart still has only library-level privacy.

Library-level privacy with identifiers starting with an underscore is also enforced at runtime.

The analyzer provides some additional features during static analysis which are ignored at runtime though.

Per convention also libraries inside lib/src are considered private, and should now be imported from other packages. The linter, a plugin for the analyzer notifies about violations. Seems to be part of the analyzer itself.

The meta package provides some annotations that are supported by the analyzer.

• @protected produces a warning if public members are referenced by code from other libraries that is not within subclasses.

• @visibleForTesting produces a warning if public members are references by code that is not within the test directory (of the same package I assume) Not sure if the analyzer actually warns about violations yet, otherwise it's planned to do that.

As far as I remember there are some issues for more rules but not yet implemented.

From @lrn's comment below

One reason for the current design is that Dart allows dynamic calls, even in strong mode. That means that o.foo() cannot be rejected based on "class level privacy" without retaining and checking extra information at runtime. With library/lexical based privacy, it's absolutely clear whether o.foo() or o._foo() is allowed (it always is, it's just that the latter can only refer to the _foo name of the same library). If Dart only had static resolution of identifiers, then it could use static information (like a private declaration) to reject at compile time without a runtime overhead.