<p>In Java or C++, there are no computed properties. Either there is a simple property that can be accessed or set with no strings attached, or a getter/setter method, that can do anything alongside getting or setting the value.</p>
<p>In other languages, such as Swift or Dart, you can have computed properties. They are accessed the same way as <em>'simple'</em> properties, but can do any amount of other computation as a method could.</p>
<p>I prefer the former, as then, any plain property access is <strong>known</strong> right off the bat to be a simple operation with no <em>'funny business'</em> behind the scenes, such as I/O, program-visible side effects, computationally expensive operations, etc. A method, however, would imply the possibility of such.</p>
<p>But are there good reasons to include computed properties or variables?</p>

<methods><properties>
What are the advantages of supporting computed properties?
CC BY-SA 4.0
2023-07-02T01:34:03.470Z
I think this is worded much better than the dupe target, but it's a pretty cut-and-dry dupe I think. Could be worth asking OP of the other one if it would be okay to edit  it to be more like this one
rydwolf
CC BY-SA 4.0
2023-07-02T03:02:03.383Z
I think these are strictly speaking different questions: the proposed duplicate is about providing *syntactic support* in the surface language while this one is about providing *the semantic capacity* in the execution model, and present answers on both reflect those framings. A question could encompass both, though, just at the moment they don't.
Michael Homer
<p>Personally, I avoid computed properties even when writing in languages which support them, and I would not include them in a language I designed. The problem is that they make it harder to reason about code, both for human readers and for compilers.</p>
<p>In a language like Java, which does not have computed properties, the following are all guaranteed:</p>
<ul>
<li>Reading or writing a property takes O(1) time.</li>
<li>Reading the same property twice in succession gives the same value, if that property can't be reassigned in between.</li>
<li>Reading a property has no observable side-effects, and writing has no observable side-effect other than that property's value changing.</li>
<li>Reading or writing a property does not require dynamic dispatch based on the object's class.</li>
</ul>
<p>Most of these are things you can <em>reasonably</em> expect of computed properties in sane code, but it's not practical for a language to enforce them as rules. Then, bugs will happen because a computed property ends up not being as well-behaved as people reasonably assume it should be.</p>
<p>Additionally, compilers normally can't assume that the code they compile is well-behaved, so in the presence of computed properties they cannot apply certain optimisations. For example, if <code>x</code> and <code>y</code> are computed properties then <code>this.x * this.x + this.y * this.y</code> must compute both twice, just in case a subclass overrides how those properties are computed.</p>
<p>Well, the programmer could write it like</p>
<pre class="lang-rs prettyprint-override"><code>let _x = this.x;
let _y = this.y;
return _x * _x + _y * _y;
</code></pre>
<p>But high-level languages shouldn't require users to write code like this just to help the compiler optimise things that should be trivial.</p>
<hr />
<p>To address <a href="https://langdev.stackexchange.com/a/1834/89">Michael Homer's point</a> about the Uniform Access Principle (UAP), this is why Java classes typically expose properties via getter and setter methods. Making property accesses into explicit method calls is a way to abide with the UAP, since the caller doesn't have to know if they are backed by a &quot;real&quot; or &quot;computed&quot; property.</p>
<p>Many people dislike getter methods, but they do at least allow changing the behaviour without changing the API. Also, I think part of the dislike for getter methods is due to Java's convention of naming them like <code>getX()</code> instead of just <code>x()</code>; in your own language you can choose a better convention.</p>

CC BY-SA 4.0
2023-07-01T23:40:47.933Z
2023-07-01T23:49:51.863Z
2023-07-01T23:49:51.863Z
kaya3
CC BY-SA 4.0
2023-07-06T19:15:24.977Z
Who says I have to follow Java's convention? While writing Java, I always call my getter functions just `x()` the same way `Enum.values()` or `Enum.ordinal()` IIRC.
CPlus
CC BY-SA 4.0
2023-07-24T09:13:44.823Z
"Who says I have to follow Java's convention?" ─ that would be other Java programmers who have to interact with your code in some way. My answer here doesn't say you have to, though.
kaya3
<p>Meyer's <a href="https://en.wikipedia.org/wiki/Uniform_access_principle" rel="noreferrer">Uniform Access Principle</a> says that</p>
<blockquote>
<p>All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.</p>
</blockquote>
<p>The idea, in broad terms, is that <strong>distinguished storage properties are an abstraction leak</strong>: they convey to the outside <em>how</em> something is implemented, but consumers of the type should not care about that, and should not <em>be able</em> to care about that. It's a little broader than just these, but computed properties are one way of providing this sort of abstraction.</p>
<p>Including <em>both</em> computed and storage properties supports program evolution: <strong>what was once made as a field can be silently replaced with something else</strong> without other code needing to be updated, or the programmer to know about it. This might happen when the data model changes, and what was originally a single field is now represented in two parts, for example.</p>
<p>Computed getters enable <strong>memoisation and deferring calculation</strong> of expensive properties unless and until they are actually read. This is something that the language could provide in other ways than general computed properties, and some do have &quot;once&quot; methods that replace themselves once called. Regardless, this can be valuable when <em>some</em> property values can be expensive to obtain (like when they require a database query), but the user of the type doesn't need to know these details, or they can vary between values. Some object-relational mappers make use of this, for example, but it can come up for almost any derived type.</p>
<p>These properties also permit <strong>validation when <em>writing</em> to a property</strong> that standard assignment does not. These can be run-time checks to preserve invariants or provide deeper assurances than the type system can support, or they can update secondary storage or derived properties. This isn't the only way to allow that; as well as the Java- or C++-style getter &amp; setter methods you mention, AOP-style pointcuts could do the same thing, as could some design-by-contract or dependent type systems. When enabling this sort of validation is useful, computed properties are one option that may add less complexity than others.</p>
<p>There are midpoints as well. The concern about a simple field access performing IO or side effects could be mitigated by requiring that these methods be pure. Expensive computation steps could be ruled out by strict complexity bounds. An IDE, or even the language itself, could allow <em>some</em> pieces of code, or their author, to opt out of this uniform access, and only access the behind-the-scenes getters and setters directly as methods.</p>
<hr />
<p>While computed properties are <em>source-compatible</em> with code that expected a storage property, they may not be ABI-compatible with code that has already been compiled. In C#, for instance, they compile down to specially-named methods and calls to those methods, while ordinary fields and field accesses do not; these methods are even accessible directly, so evolving in the computed→storage direction isn't even guaranteed to be source-compatible (given obtuse code, granted). A language that was designed with the Uniform Access Principle in mind might take a different implementation path; there is a trade-off in going either way on this, so it's always a design choice. For languages always distributed as source, like JavaScript or Python, this isn't an issue.</p>
<p>There are real costs to using these properties, and even to having them at all. Even when the computation is cheap, indirecting through a (possibly dynamically-dispatched) method call is expensive compared to a pointer offset or table lookup. There's also a burden to the programmer who cannot know exactly what happens when they access a field, and so can't necessarily gauge the complexity of their code. It's not necessarily the case that every language <em>should</em> have them, but they do have useful purposes and value when they are there.</p>

CC BY-SA 4.0
2023-07-01T06:39:43.123Z
2023-07-01T06:39:43.123Z
Michael Homer
# What are the advantages of supporting computed properties?
Posted by: username_0 on 2023-07-01
In Java or C++, there are no computed properties. Either there is a simple property that can be accessed or set with no strings attached, or a getter/setter method, that can do anything alongside getting or setting the value.

In other languages, such as Swift or Dart, you can have computed properties. They are accessed the same way as *'simple'* properties, but can do any amount of other computation as a method could.

I prefer the former, as then, any plain property access is **known** right off the bat to be a simple operation with no *'funny business'* behind the scenes, such as I/O, program-visible side effects, computationally expensive operations, etc. A method, however, would imply the possibility of such.

But are there good reasons to include computed properties or variables?
**Tags:** methods properties
> **Comments:**
> **username_1**: I think this is worded much better than the dupe target, but it's a pretty cut-and-dry dupe I think. Could be worth asking OP of the other one if it would be okay to edit  it to be more like this one  
> **username_2**: I think these are strictly speaking different questions: the proposed duplicate is about providing *syntactic support* in the surface language while this one is about providing *the semantic capacity* in the execution model, and present answers on both reflect those framings. A question could encompass both, though, just at the moment they don't.  
---
## 2 answers
### Answer by username_2 on 2023-07-01. Score: 6 | Accepted answer
Meyer's [Uniform Access Principle](https://en.wikipedia.org/wiki/Uniform_access_principle) says that

> All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

The idea, in broad terms, is that **distinguished storage properties are an abstraction leak**: they convey to the outside *how* something is implemented, but consumers of the type should not care about that, and should not *be able* to care about that. It's a little broader than just these, but computed properties are one way of providing this sort of abstraction.

Including *both* computed and storage properties supports program evolution: **what was once made as a field can be silently replaced with something else** without other code needing to be updated, or the programmer to know about it. This might happen when the data model changes, and what was originally a single field is now represented in two parts, for example.

Computed getters enable **memoisation and deferring calculation** of expensive properties unless and until they are actually read. This is something that the language could provide in other ways than general computed properties, and some do have "once" methods that replace themselves once called. Regardless, this can be valuable when *some* property values can be expensive to obtain (like when they require a database query), but the user of the type doesn't need to know these details, or they can vary between values. Some object-relational mappers make use of this, for example, but it can come up for almost any derived type.

These properties also permit **validation when *writing* to a property** that standard assignment does not. These can be run-time checks to preserve invariants or provide deeper assurances than the type system can support, or they can update secondary storage or derived properties. This isn't the only way to allow that; as well as the Java- or C++-style getter & setter methods you mention, AOP-style pointcuts could do the same thing, as could some design-by-contract or dependent type systems. When enabling this sort of validation is useful, computed properties are one option that may add less complexity than others.

There are midpoints as well. The concern about a simple field access performing IO or side effects could be mitigated by requiring that these methods be pure. Expensive computation steps could be ruled out by strict complexity bounds. An IDE, or even the language itself, could allow *some* pieces of code, or their author, to opt out of this uniform access, and only access the behind-the-scenes getters and setters directly as methods.

---

While computed properties are *source-compatible* with code that expected a storage property, they may not be ABI-compatible with code that has already been compiled. In C#, for instance, they compile down to specially-named methods and calls to those methods, while ordinary fields and field accesses do not; these methods are even accessible directly, so evolving in the computed→storage direction isn't even guaranteed to be source-compatible (given obtuse code, granted). A language that was designed with the Uniform Access Principle in mind might take a different implementation path; there is a trade-off in going either way on this, so it's always a design choice. For languages always distributed as source, like JavaScript or Python, this isn't an issue.

There are real costs to using these properties, and even to having them at all. Even when the computation is cheap, indirecting through a (possibly dynamically-dispatched) method call is expensive compared to a pointer offset or table lookup. There's also a burden to the programmer who cannot know exactly what happens when they access a field, and so can't necessarily gauge the complexity of their code. It's not necessarily the case that every language *should* have them, but they do have useful purposes and value when they are there.
---
### Answer by username_3 on 2023-07-01. Score: 5
Personally, I avoid computed properties even when writing in languages which support them, and I would not include them in a language I designed. The problem is that they make it harder to reason about code, both for human readers and for compilers.
In a language like Java, which does not have computed properties, the following are all guaranteed:

Reading or writing a property takes O(1) time.
Reading the same property twice in succession gives the same value, if that property can't be reassigned in between.
Reading a property has no observable side-effects, and writing has no observable side-effect other than that property's value changing.
Reading or writing a property does not require dynamic dispatch based on the object's class.

Most of these are things you can reasonably expect of computed properties in sane code, but it's not practical for a language to enforce them as rules. Then, bugs will happen because a computed property ends up not being as well-behaved as people reasonably assume it should be.
Additionally, compilers normally can't assume that the code they compile is well-behaved, so in the presence of computed properties they cannot apply certain optimisations. For example, if x and y are computed properties then this.x * this.x + this.y * this.y must compute both twice, just in case a subclass overrides how those properties are computed.
Well, the programmer could write it like
let _x = this.x;
let _y = this.y;
return _x * _x + _y * _y;

But high-level languages shouldn't require users to write code like this just to help the compiler optimise things that should be trivial.

To address Michael Homer's point about the Uniform Access Principle (UAP), this is why Java classes typically expose properties via getter and setter methods. Making property accesses into explicit method calls is a way to abide with the UAP, since the caller doesn't have to know if they are backed by a "real" or "computed" property.
Many people dislike getter methods, but they do at least allow changing the behaviour without changing the API. Also, I think part of the dislike for getter methods is due to Java's convention of naming them like getX() instead of just x(); in your own language you can choose a better convention.
> **Comments:**
> **username_0** (2023-07-06): Who says I have to follow Java's convention? While writing Java, I always call my getter functions just `x()` the same way `Enum.values()` or `Enum.ordinal()` IIRC.  
> **username_3** (2023-07-24): "Who says I have to follow Java's convention?" ─ that would be other Java programmers who have to interact with your code in some way. My answer here doesn't say you have to, though.  
---
