Repository navigation
Abstract Properties #4669
Description
Activity
+1
Also abstract getters should be full-fillable by properties:
abstract class A { abstract get p(); } class B extends A { p; }
This is a pretty common pattern in Dart when the abstract class just need some values by it's implementers.
Reacted by Mirodil, Zdeněk Mlčoch and Landa Kévin+1 angular has been wishing for this as well:
https://github.com/angular/angular/blob/a88e6f31063ac3abb439f93cbbc3a46c065f7614/modules/angular2/src/core/compiler/element_ref.ts#L60
cc Tobias Bosch (@tbosch)declaring the property as abstract does not change anything different from just declaring it. the type is going to always have the property.
As for getters and setters., the type system does not differentiate between getter/setter and a property declaration.
Mohamed Hegazy (@mhegazy) Actually, there is an important difference. Using an abstract property I could specify that the property must be specialized (usually with getters and/or setters) in a derived class, and the compiler should rise an error if it's not specialized.
Please reconsider closing this proposal.
Reacted by Zdeněk Mlčoch, Calvin, Adrian Moos, Yannick Stachelscheid, Spencer Kaiser and ChristinaMohamed Hegazy (@mhegazy) I totally agree with Denis Nedelyaev (@denvned) about enforcing getter declaration in child classes.
The lack of abstract properties allows child classes to simply ignore some important properties in my contracts.
Please reopen this for further discussion...
+1
Especially as lambda/arrow functions are actually properties as I found out when I was trying to implement the following functionality but it wouldn't compile due to....
"Class 'Base' defines instance member function 'def', but extended class 'Concrete' defines it as instance member property"...
abstract class Base { abstract abc(): void; abstract def(): void; } class Concrete extends Base { private setting: boolean; public abc(): void { this.setting = true; } public def = (): void => { this.setting = false; } }Reacted by Hernan Rajchert, Eddie Xie and cguinnupPlease reopen for discussion!
Here is a simple example describing the problem:
abstract class Foo { abstract getName(); //works like a charm abstract setName(value); /* but it's better to use properties: abstract get name(); abstract set name(value); */ /* I can define properties */ private _name = ''; get name() { return this._name; } set name(value) { this.name = value; } /* but cannot force Bar class to implement them */ } class Bar extends Foo { //complains only about getName and setName }
Compiler complains about undefined getName and setName but I can't define property contract.
But hey, JS and TS both support getters/setters - why should I use Java-style methods instead of properties?Reacted by Nikhil26 remaining items
Mohamed Hegazy (@mhegazy) hand this one off?
- assigned and unassigned
on Feb 1, 2016 PRs are welcomed also.
Note, the conclusion form the design discussion was
abstract readonly p: numberwas the desired order of modifiers.#7184 allows for abstract properties (and accessors). There's not much to the change because the machinery is the same as for abstract methods.
Awesome 👍
Which version is this landing in?
It should already be in
typescript@next. It will ship in 2.0.Reacted by Kotodevochka and Kevin UptonReacted by Matt Searles, Umed Khudoiberdiev, Josh Glazebrook, bancego, alanng86, Ken Hodler, Angelo Perera, Alexandru Sfirlogea, Joshua Clanton, Herrington Darkholme and 23 moreReacted by ThomasReacted by Elephant-Vessel, Joel Hernández, Fennec Cooper and Kevin Upton- locked and limited conversation to collaborators
on Jun 19, 2018
This is a proposal to extend #3578 to allow abstract properties in abstract classes. So the following should be legal: