5 ms·

I would phrase it like that: most languages (C++/Java/.NET) have unhealthy obsession with creating unnecessary setters/getters, paying for it with increased com

by kjksf 9y ago

I would phrase it like that: most languages (C++/Java/.NET) have unhealthy obsession with creating unnecessary setters/getters, paying for it with increased compile time, code bloat, slower code. In Java/C# land refactoring tools even give one-click access to "create me some setters/getters". This is not to say that abstracting access with functions has no place, but if all they do is get/set the value, they are unnecessary.

surye 9y ago
C# and Python (for examples) don't use getters and setters, they use properties which provide the same interface as direct access variables when the need arises for more complexity, client code doesn't need to know about it. Languages without this feature needs to make everything getter/setter if they don't want to break the API when something needs additional logic.
- fancy_pantser 9y ago
  Python does have properties, which work via decorators @property (which decorates a getter) and @foo.setter.
  - typon 9y ago
    He literally just said that
- TazeTSchnitzel 9y ago
  And indeed Go code has its fair share of (otherwise) unnecessary getters because of this.
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 ago
    It 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 ago
  Instead 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 ago
  Souns like get/set in swift for me. Does it have computed properties too?
  - 9y ago
deleted 9y ago
[deleted]
vkou 9y ago
So, let's suppose you don't create getters or setters, because all that function does is get/set the value. Six months later, you discover that you, in fact, do need to do something besides getting/setting the value. If you created a getter/setter, you could just change its code. If you, instead, had raw access to the field, you now need to update every single instance of client code that called your getter/setter. Most of the time, your compiler/VM can optimize the getter/setter call away, and a bunch of trivial get/set logic isn't exactly the worst source of cognitive overhead.
- kjksf 9y ago
  There are infinite possible futures but only one now. Write the best possible code needed today. Anything else is premature abstraction. I do get the "what if" temptation, I just think it should be actively resisted.
  - osteele 9y ago
    See [YAGNI](http://wiki.c2.com/?YouArentGonnaNeedIt http://wiki.c2.com/?YouArentGonnaNeedIt). A helpful (to me) metaphor is that you're paying for an option. (In the finance sense, not the type system sense.) Sometimes it's worth buying an option, sometimes it's not, but don't think it's free.
    - astrobe_ 9y ago
      A more simple analogy: it's an insurance. It's certainly wise to subscribe an insurance for your house, but for every single drinking glass you own...? If it's a tea set you inherited from your great-grand-mother, when you break it the insurance won't un-break it. If your property suddenly needs to be more than a property, chances are that this change will break the LSP or trigger a larger redesign anyway.
  - MrBuddyCasino 9y ago
    This not one of those instances though. The cost of having getters/setters is essentially zero, the potential downside can be big.

by kjksf 9y ago

surye 9y ago

C# and Python (for examples) don't use getters and setters, they use properties which provide the same interface as direct access variables when the need arises for more complexity, client code doesn't need to know about it. Languages without this feature needs to make everything getter/setter if they don't want to break the API when something needs additional logic.

fancy_pantser 9y ago
Python does have properties, which work via decorators @property (which decorates a getter) and @foo.setter.
- typon 9y ago
  He literally just said that
TazeTSchnitzel 9y ago
And indeed Go code has its fair share of (otherwise) unnecessary getters because of this.

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 ago
  It 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 ago
Instead 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 ago
Souns like get/set in swift for me. Does it have computed properties too?
- 9y ago

deleted 9y ago

[deleted]

vkou 9y ago

So, let's suppose you don't create getters or setters, because all that function does is get/set the value. Six months later, you discover that you, in fact, do need to do something besides getting/setting the value. If you created a getter/setter, you could just change its code. If you, instead, had raw access to the field, you now need to update every single instance of client code that called your getter/setter. Most of the time, your compiler/VM can optimize the getter/setter call away, and a bunch of trivial get/set logic isn't exactly the worst source of cognitive overhead.

kjksf 9y ago
There are infinite possible futures but only one now. Write the best possible code needed today. Anything else is premature abstraction. I do get the "what if" temptation, I just think it should be actively resisted.
- osteele 9y ago
  See [YAGNI](http://wiki.c2.com/?YouArentGonnaNeedIt http://wiki.c2.com/?YouArentGonnaNeedIt). A helpful (to me) metaphor is that you're paying for an option. (In the finance sense, not the type system sense.) Sometimes it's worth buying an option, sometimes it's not, but don't think it's free.
  - astrobe_ 9y ago
    A more simple analogy: it's an insurance. It's certainly wise to subscribe an insurance for your house, but for every single drinking glass you own...? If it's a tea set you inherited from your great-grand-mother, when you break it the insurance won't un-break it. If your property suddenly needs to be more than a property, chances are that this change will break the LSP or trigger a larger redesign anyway.
- MrBuddyCasino 9y ago
  This not one of those instances though. The cost of having getters/setters is essentially zero, the potential downside can be big.