Allow an extension to provide the missing part of a getter/setter pair

[eernstg]

We could allow a getter/setter pair to consist of one member declared for the receiver type (as a member of a class, mixin, mixin class, enum, or extension type) and the other member declared by an applicable extension.

See dart-lang/web#357 for a discussion which motivates this proposal. In that issue, the point is that a JS interop extension type needs to have an operator [], and we wish to use an extension to provide support for an operator []= ([]/[]= are considered to be a getter/setter pair). This fails to work because the operator []= in the extension is shadowed by the operator [] in the receiver type (when we have found the "getter", we don't even try to look for the "setter" in an extension, and vice versa). For example:

extension on A {
  set x(int _) {}
}

class A {
  int get x => 0;
}

void main() {
  A().x = 0; // Error today, OK with this proposal.
}

It seems both useful and benign (in particular: non-breaking) to allow extensions to provide the missing part of a getter/setter pair.

The corresponding specification change could be achieved as follows. The following phrase:

(2) the interface of the static type of $r$ does not have a member
whose basename is the basename of $m$,

should be adjusted as follows:

(2) the interface of the static type of $r$ does not have a member named $m$,

[Edit, April 28th: The above wording won't quite work, we need to prevent the case where the receiver type has a setter and the extension has a method, and vice versa. This could give rise to some slightly bigger changes. Thanks to @lrhn for noticing this issue.]

@dart-lang/language-team, WDYT?

[lrhn]

We chose to disallow properties declared partly by extensions and partly by interfaces. (Or declared by different extensions.)
Mainly out of the idea that a getter/setter pair is logically "one property", and we try to prevent mixing different properties into what looks like the same property.

Did we use to prevent one import providing x and another providing x=? I seem to remember something at some point.
It's not prohibited today, so that's precedence in direction of allowing it.

If we choose to losen this restriction, we should do it consistenty. An extension will only be applicable if it has a member with the name, not the base name, of the invoked member.
Today an extension on Object { int get x => 42; } and an extension on Object { set x(int _) {}; } would conflict for both .x and .x=, since both are considered applicable due to the base-name check. If we ignore conflicts with instance members, we should just be consistent and do it everywhere, also between different extensions.
(Also check if extension types have any "basename" checks. I don't think it has, but it repeats the extension resolution, so it should be updated there too. Probably check the dot-shorthand spec as well, and check if it uses basename for something, but we don't have static extensions yet, so it doesn't need to repeat extension lookup.)

I have no problem with allowing this, if we do it consistently. Everywhere an extension checks for a similarly named member, it should use the name instead of the base name.

It does split the getter and setter more apart, treating them as completely individual declarations. But they are completely distinct from the language's perspective, and if you don't like that, just don't do abuse it.

[eernstg]

I think we agree on this part: We only lift the restriction on receiver type declarations (class, mixin, mixin class, enum, extension type declarations) relative to extensions. I don't want to allow the getter to come from an enclosing class and the setter to be a top-level declaration, and things of that nature. In contrast, an extension member is intended to be similar to a member which is declared in the receiver type declaration. Also, the author of an extension is aware of the interface of the on-type of that extension, which means that it is reasonable to assume that the getter and the setter are semantically compatible. These things make it rather natural to allow that particular case.

[eernstg]

We could also consider allowing the getter and the setter to be provided by two distinct extensions. However, there is no similar justification for this relaxation: Nothing ensures that the authors of the two extensions are aware of each other, so there's no reason to assume that they are semantically compatible.

[eernstg]

Did we use to prevent one import providing x and another providing x=?

This is #1784, a piece of technical debt.

[lrhn]

Nothing ensures that the authors of the two extensions are aware of each other, so there's no reason to assume that they are semantically compatible.

There is no more guarantee that a class setter and extension getter are aware of each other. For all we know, the class setter could have been added last.

The only kind of guarantee in either case would be that the declarations are in the same library.

If you have a class getter and someone else adds an extension setter, and you change the getter to be an extension instead, I don't see why that should suddenly become an error.

If we only look for extensions with a member which has the same name, then it'll just work. If one extension adds a getter and another a setter, then only one will be applicable to any invocation.

A more serious issue is that this allows a class method and an extension getter with the same base name. Or two equally specific extensions where one adds a setter and the other a method. Unless we want to allow a single class to declare both, we probably want to disallow that.

So:

And extension members is applicable if the extension's on clause matches the target type, and the target type does not have an instance member with the same base name, or if the extension is a getter, and the only target type instance member with the same base name is a setter, or the extension member is a setter and the only target type instance member with the same base name is a getter.

This is a change of terminology. It used to be that an extension was applicable, not its member, because we didn't care what the members were, just that there was one with the same name.

With this, a class with a getter would allow an extension with a getter and setter to have the setter be applicable, and it ignores the getter (of both class and extension).

But we shouldn't just be using "name" if that allows method+setter overloading.

[eernstg]

If we wanted, we could obviously eliminate all rules about getters and setters being conceptually connected. We have already decided that they don't have to satisfy any constraints when it comes to the getter return type and the setter parameter type, and this means that it is quite easy to implement the fully disconnected semantics, we just need to treat the getter as a completely independent member and similarly for the setter, no matter how and where they are declared.

However, I do think it is useful to maintain that a getter/setter pair can be considered as a single conceptual entity (a "property"), simply because the reading complexity of any portion of Dart software will grow if we have to constantly remind ourselves that the getter x and the setter x= (typically accessed using syntax like x = ..., making it awfully similar to the getter) have nothing to do with each other, and each of them must be understood from scratch, separately.

I really don't want to go there.

So the question would be where to draw the line.

There is no more guarantee that a class setter and extension getter are aware of each other. For all we know, the class setter could have been added last.

That is true, but it is still a reasonable assumption that extension instance members can be understood relative to the receiver type instance members. That is, extension authors can generally be relied upon to know the receiver type interface, and write their extension member declarations in such a way that they make sense when considered together with the members of the receiver type. The situation where the class interface is updated after the related extension members have been written is an anomaly that calls for a revisit and possibly some adjustments. In particular, this is needed in order to ensure that we can preserve the simple and convenient perspective that a getter and a setter with the same basename work together to provide a conceptual property.

Now we have a concrete case where there are good reasons why we might want to allow a property to consist of a receiver type getter and an extension setter, which is the reason why I'm suggesting that we should relax that case. The opposite (a receiver type setter and an extension getter) seems to be less likely to arise in practice, but would be justified by the same kind of argumentation.

I'm not sure about the extension/extension case, but I do think that it is less well justified.

Finally, I do not think that we should allow a setter/getter pair to be provided by any other combination of namespaces (e.g., a top-level setter and an instance getter in the interface of the enclosing class).

A more serious issue is that this allows a class method and an extension getter with the same base name ...
Or two equally specific extensions where one adds a setter and the other a method

Good catch!

I'd certainly want to avoid a method/setter combo, no matter where the setter and the method are declared.

[lrhn]

I'm not convinced that this single example is reason enough to break the "better and setter is one property" rule.
It is very simple, but it's consistent.
(Has the issue been fixed? I couldn't see any operator [] on Window.)

If we do start breaking that rule to allow extensions to add the other part of the getter/setter pair to an existing partner, I will prefer to allow it generally, independently of how the other part was declared, even of that happened to also be an extension method.

Either we treat extension methods as similarly to instance members as possible, or we don't.
That the existing member happened to be an extension shouldn't matter.

[eernstg]

I do not want to drop the bundling of getters and setters in general, but I do think it could make sense to lift the restrictions slightly such that a class/mixin/enum/extension-type getter can be paired with an extension setter, and vice versa.

By the way, do you have a better solution for the original example in dart-lang/web#357?

[lrhn]

The solution I'd use would be:

• Have Window add an operator[]=,
• change the []/[]= of the extension to use another name, like getProperty/setProperty,
• use an explicit extension application JSObjectUnsafeUtilExtension(window)[key] = value, or
• cast to JSObject: (window as JSObject)[key] = value.

Any of the ways you normally deal with a conflict between an instance member and an extension.

(It wouldn't work to make Window.[] an extension member.)

I'm also OK with allowing extension setters/getters to coexist with another getter/setter, but I'm against making that special to instance member + extension member.

We treat extension member similarly to instance members, as much as possible, so that you can (somewhat) change an instance member to an extension member, and not break people. (Much, if they rememeber to import it.)

An extension member is then allowed to be combined with another member, because we are treating it as if it was an instance member on the target type, and then it's on the same type, and all is well.

But then we should be consistent and allow it to be combined with another "similar to an instance member" extension member, because we treat both as members of the target type.

Otherwise we would fix this problem, but would still have the same problem if Window decided to make operator[] an extension method, for whatever reason.

Allowing only instance + extension, but not extension + extension, feels ad-hoc, like a minimal change to solve this particular issue, not like a full feature.

[eernstg]

@lrhn mentioned this in a list of possible solutions to the issue dart-lang/web#357 where this discussion came from:

Have Window add an operator[]=,

I suggested this in the discussion in dart-lang/web#357.

@srujzs, I believe the reason why you did not want to do this was that Window should not normally have such an operator: It is an unsafe operation, and developers can add it by importing 'dart:js_interop_unsafe', but they shouldn't have to remember to avoid using it in normal (safe) interop code, it just shouldn't be there.

I think the situation is as follows:

• JS interop types do not have an operator []= in general.
• Most JS interop types can effectively add an operator []= by adding that import.
• However, the operator []= is inaccessible for those JS interop types that have an operator [], so it's exactly those types that seem to be the most natural "home" for an operator []= that won't get it.

As far as I can see, the relaxation which is proposed in this issue would be a pretty nice solution for that problem.

It could be argued that this behavior should be obtained using a different name (@lrhn mentioned setProperty), which would also solve the problem. The argument against this solution would be that developers who know JavaScript will, most likely, be much more happy if they can use familiar syntax also in Dart interop code, rather than having to learn and remember that this particular thing is written differently (jsObj.setProperty('property', something) rather than jsObj['property'] = something).

@lrhn wrote:

Allowing only instance + extension, but not extension + extension, feels ad-hoc, like a minimal change to solve this particular issue, not like a full feature.

I could live with a change where extension + extension is allowed as well. Note that we also allow a class to have a getter and a setter where one mixin provides one and another mixin provides the other (and the mixins are not guaranteed to have been written by authors who know anything about each other, so they can also be arbitrarily mispaired).