3 ms·

How many times have you run into this in your career (the need to convert "today's fields to tomorrow's computer properties")?

• shabbyrobe 9y ago
  Plenty of times! The situation where a library released to third parties requires internal structural changes is not an uncommon one. What do you do? Break every piece of third party code or satisfy the new structure and the old interface simultaneously with a computed property? "Move fast and break stuff" doesn't always have to include breaking stuff.
• AlphaSite 9y ago
  Aside, from what the other poster mentioned, one major advantage is that I don't want to write getXXX and setXXX, everywhere where I do need computed properties, does it matter if the value is precomputed or lazy computed (for example for a float derived from another float)?
• millstone 9y ago
  Honestly, many times. A common occurrence is singular evolves to multiple: "the touch position" becomes "the touch positions," "selected item" becomes "selected items", etc. The backing storage switches from T to [T]. In this scenario it's easy to make the old method do something sensible like "return the first item." But maintaining an old field is more difficult: you can't make it lazy, you can't eliminate its backing storage, etc.
• dtech 9y ago
  Quite often, especially if you make a variation of an existing class (or an extra type in an ADT). Scala does this quite transparent. Something defined as a `var` (variable), `val` (immutable variable), `lazy val` (lazy immutable variable) or `def` (method) is called source- and binary compatible from the caller side. I've never seen this trick anyone, except for maybe unexpected bad performance.
• kimi 9y ago
  Enough times that I remember it. Luckily, with modern IDEs, going from fields to accessors is just a "refactoring" menu away.