escamoteur
commented
1 month ago Protected members are non-virtual, non-interface methods. They can be shadowed by other protected or non-protected members. They become virtual only when made public by being given a interface signature, without introducing new implementation.
I don't really understand this paragraph. why can they be shadowed? and why aren't they virtual?
class A {
protected void protectedFunc(){
print('in A');
};
void init(){
protectedFunc();
}
}
class B extends A{
@override
protected void protectedFunc(){
print('in B');
}
}
B b;
b.init(); // -> should call B.protectedFunc() and not the one of A
lrhn
tatumizer
mateusfccp
This is an attempt at a full feature specification for protected instance members, as another solution to #835. Edit: And this is version 2 where the protected members can be overridden by subclasses.
Dart protected instance members
Dart has only one notion of declared access restriction: Library privacy.
Having private names solves two problems: Avoiding internal implementations having name clashes with third-party code, and ensuring what third-party code is able, and not able, to access, which makes it easier to ensure invariants.
Since the author controls the size and scope of a library, and is expected to be fully cooperative with all code they have the power to modify anyway, that’s a rather sweet spot of privacy. By scoping a library to a single class, or to what would be an entire directory of files in another language, the author can choose anything between class privacy and “package privacy”. It’s an accessibility where the author can control the scope.
One accessibility feature that other object oriented languages have, and that Dart cannot emulate with library privacy, is protected access: Instance members of a class which can only be accessed from subclasses which extend that class.
Protected members are useful for reusable libraries. A library can expose a base or skeleton class that third-party subclasses can extend to provide customized classes. However, if the subclass needs to interact with the base class, it can currently only do so if the base class exposes public API, which then contaminates the public API of the subclass with operations that end-users shouldn’t be using.
Dart provides the
@protectedannotation which makes the analyzer warn if a non-subclass invokes the annotated member. That’s not a safe solution, the API is still public and accessible, anyone can choose to ignore the warning.Instance protected members
We add instance members that can only be accessed and invoked by subclasses. Such a member can be declared in a
class,enumormixindeclaration. It’s available to any class which has theclassorenum, or an application of themixin, in its superclass chain. This includes the class itself — and for enums, nothing else.Syntax
The immediate choice is to make
protecteda built-in identifier and use it as a modifier on any instance member declaration:Since protected members cannot be static, we just have to decide where it goes relative to other modifiers. Let’s say after
external, beforeabstract, approximately the same place asstatic.Let’s go with this, it can be changed if we have a better idea.
The grammar is updated to allow
protectedon any non-static, non-constructor member declaration. (Grammar taken fromDart.g, skipping theaugmentdeclarations for now. They may or may not need to repeat theprotected.):Semantics
We ensure that the modifier is only allowed where it makes sense. We introduce the following new rules and changes, with anything not mentioned assumed to work the same for protected members as for any other instance member.
class,mixinorenumdeclaration. (Not allowed insideextensionorextension typedeclarations.)class,enumormixindeclaration declares a protected member, and any superinterface of the containing declaration has a non-protected member signature with the same name. If a member is already public, the protected declaration is misleading and probably an error.protected.The behavior of a correctly declared protected member is:
A protected member declaration works just like any other instance member declaration, except that the member signature it introduces into the interface is protected, unless any superinterface has a non-protected member with the same name. Protected interface members are special wrt. accessibility and inheritance through
implements, but otherwise work as normal. An interface member can only be protected if all super-interface members of the same name are protected, otherwise it falls back to being “public”.The combined super-interface of a
class,mixin,enumorextension typedeclaration is computed almost like today, except:implementsclause are omitted. (If the implementation is not inherited, nor is the protected interface member signature.)This computation affects the interface of the declaration itself, if it does not declare any members with the same name. It also affects the members available to a mixin through its
ontypes. A mixin has a protected member if itsontype does.A protected member is considered inaccessible when accessed through a typed member invocation for any receiver other than
this. DoingFoo o = ...; o.id();whereFoo's interface has a protected member namedid, is a compile-time error, becauseFoodoes not have an accessible member namedid.A protected member cannot be invoked through a dynamic invocation either. In a dynamic invocation, if an instance member is found which is protected in the interface of the receiver’s runtime type, dynamic invocation treats it as an inaccessible member and invokes
noSuchMethod(it’s anoSuchMethod-thrower).Protected members can only be invoked through
superorthisinvocations (including the implicitthis.for plain identifiers that are not in the lexical scope).If invoked through
super, a protected member works just like any othersupermember invocation, directly invoking the implementation of the member. Super member invocations do not use the interface of the superclass, but directly invokes the implementation. They ignore whether a member is protected.In a mixin, a
super-member invocation can invoke a protected member of anontype. As usual, anysuper-member invocation in a mixin requires all concrete superclasses the mixin is applied to to have a valid implementation of that member.If invoked through
this, a protected member works just like any other instance member invocation, except that it does not consider protected members as inaccessible.Summary
protected, on any instance member of aclass,mixinorenum, which marks it as protected in the class interface.thisorsuper. That’s what the flag is used for, disallowing any other invocations.implements, only through superclass relation.protecteddeclaration of the same name. Once public, always public.