Repository navigation
Improper usage of properties with missing set / get should be an error #295
Description
If a property has a getter but no setter (or vice versa) than perhaps the attempt to set or get should be flagged as an error:
class Fields{
get ReadOnly(){
return 10;
}
public written:number;
set WriteOnly(value:number){
this.written = value;
}
}
var obj = new Fields();
console.log(obj.ReadOnly); // 10
obj.ReadOnly = 20; // cannot set but no error
console.log(obj.ReadOnly) // 10
obj.WriteOnly = 20;
console.log(obj.written) // 20
console.log(obj.WriteOnly); // cannot read but no error No biggie. But something to be aware of. (ported from http://typescript.codeplex.com/workitem/834)
Activity
danquirk commentedon Jul 29, 2014
It certainly would be nice. The biggest problem here is that getter/setter and properties are not differentiated at the type level. That is, the .d.ts for the above type is:
so obviously you now can't do any of these kinds of checks unless you have the full implementation to inspect. If we did #12 then this kind of checking would likely fall out of that nicely so I'm just going to close this.
myitcv commentedon Sep 18, 2015
Dan Quirk (@danquirk) looking at the issues that are linked to #12, it seems the vast majority relate to this issue, namely the silent treatment of accessing non-existent getters/setters.
Is there something preventing getters/setters being differentiated at the type level?
joelday commentedon Jan 2, 2016
Dan Quirk (@danquirk) This needs to be deduped from #12. This is about a compile time error for a guaranteed run time failure.
KoenT-X commentedon Apr 15, 2016
I just ran into this very same bug. If there is no setter for a property, then an error should be flagged (or at least a warning).
AGiorgetti commentedon Jul 21, 2017
Yep, I still hit this error times and times again (especially in TypeScript code written by people that start using the language right away without looking into it deeply).
" it compiles, so it should just work" this is what they say...