3 ms·

Pattern Matching with Is Expressions Awesome! Greatly reduces "ugly" boilerplate code like this: if (control is TextBox) { var textBox = (Text

by batina 10y ago

Pattern Matching with Is Expressions Awesome! Greatly reduces "ugly" boilerplate code like this: if (control is TextBox) { var textBox = (TextBox)control; textBox... } Also, it would be great if Microsoft could make full properties in another way so that you do not have to write a backing field for it. Something like this: public string LastName { get; set { if (value == "Batina") RaisePropertyChanged(); } } It would make code more cleaner.

taspeotis 10y ago
For your second example: just use Fody.PropertyChanged and forget about writing boilerplate.
- batina 10y ago
  I know about Fody but I don't think it would help with custom logic inside setter (not just PropertyChanged call).
jsingleton 10y ago
I think if you're writing property accessors manually then there should be an explicit private backing field. Otherwise there is just too much magic going on. Normal auto-implemented properties are fine: public string LastName {get; set;} As are read-only ones: public string LastName {get; private set;} Yet, I feel that if you are writing logic in there then you should fully control it. Or else there is too much being done that is non-obvious and could cause problems down the line (for others or your future self). However, they might be able to achieve something with data annotations that wouldn't be too magic. For example: [RaisePropertyChanged("Batina")] public string LastName {get; set;} Tip: In VS you can just type "prop" then press tab to auto-generate the code for a class property. You can then easily auto-change this to a fully implemented version. This also works for "for" and "foreach" loops etc. I haven't done much Java in a while but do you still have to write out all of your property accessors fully? Might not be too bad if the IDE can generate this code.
- batina 10y ago
  I don't think its possible with data annotations because there will me more complex logic in setter then I described. I would just like to see get working like in auto-implemented property (without backing field) but setter to be manually implemented (with value keyword). Also you can use propfull snippet for full property implementation.

by batina 10y ago

taspeotis 10y ago

For your second example: just use Fody.PropertyChanged and forget about writing boilerplate.

batina 10y ago
I know about Fody but I don't think it would help with custom logic inside setter (not just PropertyChanged call).

jsingleton 10y ago

I think if you're writing property accessors manually then there should be an explicit private backing field. Otherwise there is just too much magic going on. Normal auto-implemented properties are fine: public string LastName {get; set;} As are read-only ones: public string LastName {get; private set;} Yet, I feel that if you are writing logic in there then you should fully control it. Or else there is too much being done that is non-obvious and could cause problems down the line (for others or your future self). However, they might be able to achieve something with data annotations that wouldn't be too magic. For example: [RaisePropertyChanged("Batina")] public string LastName {get; set;} Tip: In VS you can just type "prop" then press tab to auto-generate the code for a class property. You can then easily auto-change this to a fully implemented version. This also works for "for" and "foreach" loops etc. I haven't done much Java in a while but do you still have to write out all of your property accessors fully? Might not be too bad if the IDE can generate this code.

batina 10y ago
I don't think its possible with data annotations because there will me more complex logic in setter then I described. I would just like to see get working like in auto-implemented property (without backing field) but setter to be manually implemented (with value keyword). Also you can use propfull snippet for full property implementation.