Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-overridable members #27502

Closed
munificent opened this issue Oct 5, 2016 · 5 comments
Closed

Non-overridable members #27502

munificent opened this issue Oct 5, 2016 · 5 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-obsolete Closed as the reported issue is no longer relevant type-enhancement A request for a change that isn't a bug

Comments

@munificent
Copy link
Member

munificent commented Oct 5, 2016

Dart specifies that all members, including fields, can be overridden by subclasses or implemented by interfaces.

dev_compiler does not support overriding fields because it forces fields to be compiled to larger, slower JS. Strong mode in turn therefore makes overriding a field a static error.

When investigating instances of that error, Leaf discovered almost every single case where a field was being overridden was in fact bad code. In most cases, the intent for the "field" was actually to declare an abstract getter/setter.

Flutter (among others) have requested to be able to declare that some members cannot be overridden.

The language has committed to at least declaring fields that can and cannot be overridden or implemented. We have not yet decided:

  • If other members can be configured in the same way.
  • What the default should be for fields.
  • What the default should be for other members.
  • What the syntax should be.
  • What the semantics are, especially around implicit interfaces.

This bug is to decide and implement those.

See also: #24928, #27385, #27452, #27372.

@munificent munificent added the area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). label Oct 5, 2016
@munificent munificent added this to the 1.50 milestone Oct 5, 2016
@rmacnak-google
Copy link
Contributor

Non-overrideable members is completely contrary to the Dart object model. A limitation of one implementation should not poison the language.

@floitschG
Copy link
Contributor

Status update:
DDC needs to implement support for it.
Strong mode should removed the check.
Assuming that the implementation for DDC works as expected (with no overhead for normal fields), the language team doesn't take any action for 1.50.

@jmesserly
Copy link

jmesserly commented Mar 28, 2017

FYI, DDC support for this should be implemented, and I left support for Analyzer to easily re-add if needed. The "isVirtual" getter is hard coded to return true now, but it would be easy to have it return false if @sealed is present. (1c504f8)

EDIT: although note the Analyzer has a problem with checking ClassTypeAlias syntax:

class A { int x = 0; }
class M { int x = 1; }
class C = A with M;

@jmesserly
Copy link

In other words, LMK if y'all want to add Analyzer support for @sealed, it's a trivial change.

@lrhn lrhn added type-enhancement A request for a change that isn't a bug closed-obsolete Closed as the reported issue is no longer relevant labels Jun 25, 2018
@lrhn
Copy link
Member

lrhn commented Jun 25, 2018

DDC now allows overriding fields.

@lrhn lrhn closed this as completed Jun 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-obsolete Closed as the reported issue is no longer relevant type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants