"Field declaration xxx.yyy can not be overridden in zzz" in strong mode

[zoechi]

Seems to be https://github.com/dart-lang/sdk/blob/master/pkg/analyzer/lib/src/task/strong/info.dart#L460

abstract class CopyItem {
  final io.FileSystemEntity source;
  io.FileSystemEntity destination;
  CopyItem._(this.source, this.destination);
}

/// A file to copy to the deployable directory.
class CopyFile extends CopyItem {
  CopyFile._(io.File file, io.File destination) : super._(file, destination);

  @override
  io.File get destination => super.destination; // <= error
}

/// A directory to copy to the deployable directory.
class CopyDirectory extends CopyItem {
  CopyDirectory._(io.Directory directory, io.Directory destination)
      : super._(directory, destination);

  @override
  io.Directory get destination => super.destination; // <= error
}

Is this intentional?

Dart VM version: 1.13.0-edge.73b6080a6b26ad24380477c4a584edd6cb2e2ab5 (Fri Nov 13 14:15:20 2015) on "linux_x64"

[vsmenon]

Yes, this is intentional. The motivation is touched on here, but I need to expand that:

https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md#open-items

One possible fix is to place the fields with the correct type in the subclass instead:

abstract class CopyItem {
  final io.FileSystemEntity source;
  io.FileSystemEntity get destination;
  CopyItem._(this.source);
}

/// A file to copy to the deployable directory.
class CopyFile extends CopyItem {
  final io.File destination;

  CopyFile._(io.File file, this.destination) : super._(file);
}

/// A directory to copy to the deployable directory.
class CopyDirectory extends CopyItem {
  final io.Directory destination;

  CopyDirectory._(io.Directory directory, this.destination)
      : super._(directory);
}

Note, this is more efficient in checked mode and dev_compiler as it should avoid any type check on an access to destination.

[zoechi]

Ok, thanks for the explanation.
So this is only when the base class is abstract, right?

[leafpetersen]

This applies whenever you extend a class, abstract or not. If you extend something which has a field x (or which transitively extends something which has a field x), then you can't override x: neither by overriding the field, not by overriding the implicit getter/setters.

You can go the other way (override a getter and/or setter with a field).

You can also implement an interface that declares a field using a getter/setter pair.

Basically, once you have a field, you're stuck with it forever with respect to subclassing, but from the perspective of implementing an interface, a field is just a shorthand for a getter/setter pair.

[zoechi]

Thanks for the explanation!

[zoechi]

What if I want some validation or other additional logic related to the field in the constructor of the base class? It can't be the intention to add this to every subclass.
I also can't change the field in the base class to a getter/setter because I pass it with a named argument and this doesn't allow to assign to final private fields.

[zoechi]

Actually the analyzer doesn't complain about the MyClass({this._somefield}) {} constructor argument. Have to investigate more.

[vsmenon]

@zoechi - can you clarify the example you're working through? Seems different from the original comment now.

In general, if the field is final, it's more efficient to do that validation on the write (in the constructor) than on every read / getter. The original code, in checked mode, would check the type of destination on every read. The modified code (in my comment above) would not.

[zoechi]

Yup, it's a slightly different example where I run into this again.

I have to investigate more. I'm currently in the middle of a big refactoring.

Why is performance in checked mode important anyway?
Checked mode is development only, or are you considering changing that?

[zoechi]

class EventData {
  final sender;
  final dom.Event causedBy;
  EventData({this.sender, this.causedBy}) {
    if(_causedBy, ...) {
    }
  }
}

// I have dozens of such classes extending EventData
class Click extends EventData {
  final Cell cell;
  dom.MouseEvent get causedBy => super.causedBy;

  Click(sender, this.cell, {dom.MouseEvent causedBy})
      : super(sender: sender, _causedBy: causedBy);
}

class CellRangeSelected extends EventData {
  final Range range;

  CellRangeSelected(sender, this.range) : super(sender: sender);
}

I can't use this workaround because {this._causedBy} isn't allowed.

class EventData {
  final sender;
  final dom.Event _causedBy;
  dom.Event get causedBy => _causedBy;
  EventData({this.sender, this._causedBy}) {
    if(_causedBy, ...) {
    }
  }
}

class Click extends EventData {
  final Cell cell;
  dom.MouseEvent get causedBy => super.causedBy;

  Click(sender, this.cell, {dom.MouseEvent causedBy})
      : super(sender: sender, _causedBy: causedBy);
}

[vsmenon]

This is a bit annoying, but you could do:

EventData({this.sender, dom.Event causedBy}) : _causedBy = causedBy { ... }

right?