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

Type system should treat function valued getters as methods? #2849

Closed
gbracha opened this issue May 1, 2012 · 9 comments
Closed

Type system should treat function valued getters as methods? #2849

gbracha opened this issue May 1, 2012 · 9 comments
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@gbracha
Copy link
Contributor

gbracha commented May 1, 2012

Given

interface I { int f();}

class C1 implements I {
   int f() => 1;
}

typedef int G();

is

class C2 implements I {
  G get f() {return () => 2;}
}

a legitimate implementation of I? Currently, this is disallowed. Yet some have requested such functionality. After all,

new C2().f();

works just as well as

new C1().f();

@DartBot
Copy link

DartBot commented May 1, 2012

This comment was originally written by @seaneagan


Starred!

It should also work in reverse, C1 should be a legitimate implementation of:

interface I { G get f();}

Note as well that getting the Function value works the same with either implementation:

new C1().f;
new C2().f;

I think the way to spec. it is to have methods desugar into Function valued getters, which yields closurization semantics for free, and avoids needing to specify Function getters separately from other getters, which would be strange.

Also see doc linked in issue #1616 (should be merged with this issue or vice versa) for more comments.

@anders-sandholm
Copy link
Contributor

Added this to the M1 milestone.

@anders-sandholm
Copy link
Contributor

Removed this from the M1 milestone.

@anders-sandholm
Copy link
Contributor

Added this to the M1 milestone.

@gbracha
Copy link
Contributor Author

gbracha commented May 9, 2012

Removed this from the M1 milestone.
Removed Type-Defect label.
Added Type-Enhancement label.

@gbracha
Copy link
Contributor Author

gbracha commented May 24, 2012

Added this to the Later milestone.

@kasperl
Copy link

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@gbracha gbracha added Type-Enhancement P3 A lower priority bug or feature request area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels Aug 4, 2014
@gbracha gbracha self-assigned this Aug 4, 2014
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed accepted labels Feb 29, 2016
@lrhn
Copy link
Member

lrhn commented Jun 22, 2018

With the type system of Dart 2, we are going in the opposite direction from this.
I can guarantee that this will not happen short of another complete replacement of the type system.

@lrhn lrhn closed this as completed Jun 22, 2018
@lrhn lrhn added the closed-not-planned Closed as we don't intend to take action on the reported issue label Jun 22, 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-not-planned Closed as we don't intend to take action on the reported issue P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants