3 ms·
> paying for it with increased compile time, code bloat, slower code. Auto-properties in C# are one line of code, same as fields, and the getter/setter methods
by taspeotis 9y ago
> paying for it with increased compile time, code bloat, slower code.
Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off.
(Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.)
As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...
- zaroth 9y ago(smacks forehead) Wait, wait, since when can you put the default assignment right there on the same line? Go ahead, say since always... I dare you. Edit: Apparently this came in C# 6.0 (July, 2015). Ok, now I don't feel so bad. :-) On a separate note, C# might not sexy or even that popular, but I really enjoy coding in it, and the continuing evolution of the syntax is a joy.
- shpongled 9y agoIt really is a joy to program in. I fought it off for the longest time (I like regular ole C, python, dabbled in Java long ago), but finally dipped my toes in and tried C# a month ago... While the language as a whole is a bit verbose, LINQ is incredible, and the breadth of the standard library is awesome.
- MichaelGG 9y agoInstead of a field, you get a field and two methods. It's more IL, more metadata, etc. Maybe when the JIT is all done it's eliminated, but it'll cost more to JIT. Though I doubt this makes a ton of real world impact, performance wise. Stripping names would do more to shrink the .Net code.
- taspeotis 9y ago> Instead of a field, you get a field and two methods And if you wanted a publically read-only/privately mutable value without properties you'd have to write ... a field and one method. Possibly two methods if you wanted some shared validation code everywhere you assign the field. Like I said, in practice, it's the same. If you have some case where three vs. two members makes a difference you're in pathological case territory.
- DelightOne 9y agoSouns like get/set in swift for me. Does it have computed properties too?
- taspeotis 9y agopublic double Area { get { return Width * Height; } set { Width = Math.Sqrt(value); Height = Width; } } You can also use expression bodied members (that's the => syntax) with get/set. There's a shorthand if you only need to define the getter (i.e. read-only): public double Area => Width * Height;
- DelightOne 9y agoSwift has the same syntax too except the last line. Have they introducted willSet and didSet too? Neat stuff, i may try the language out in a future project on windows.
- taspeotis 9y agoThere's no direct equivalent to willSet or didSet. The closest equivalent (aside from adding code before/after your own get/set code) might be INotifyPropertyChanged [1]/INotifyPropertyChanging [2]? But they are more for external observers and add a lot of boilerplate to your code. It's possible to manage the boilerplate, however [3]. [1] https://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged(v=vs.110).aspx#Examples https://msdn.microsoft.com/en-us/library/system.componentmod... [2] https://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanging(v=vs.110).aspx#Remarks https://msdn.microsoft.com/en-us/library/system.componentmod... [3] https://github.com/Fody/PropertyChanged https://github.com/Fody/PropertyChanged