• DigitalDesigns (22/22) May 30 2018 https://dpaste.dzfl.pl/6c6e614b58ac
• Arun Chandrasekaran (4/8) May 30 2018 Please report issues at https://issues.dlang.org otherwise it
• Neia Neutuladh (29/33) May 30 2018 Here's similar bad design:
• Mike Franklin (7/30) May 30 2018 In case you're not already aware, there is a DIP in progress to

DigitalDesigns <DigitalDesigns gmail.com> writes:

https://dpaste.dzfl.pl/6c6e614b58ac

The problem given in the list, is that a ref getter is used when 
a setter does not exist. Why have a setter then?

One problem is that if the setter has different behavior than the 
getter there will be problems.

The other problem is that += modifies the value.

normally getters are thought to be immutable in the since that 
they just return a value.

but

a += will modify what a points to.

Using setters, we might want to trigger an event when the value 
changes. But since the getter is used and can modify the event 
won't be triggered.

This is a bad design.

any modifying operator should call the setter. This is precisely 
what "set mean".


a += b is suppose to be syntactic sugar for a = a + b, yet we get 
different behavior. In one case only a getter is called and in 
the second case the getter and then the setter.

How D currently handles this is wrong and error prone. Either 
depreciate the use of op assignments using properties or fix it! 
lvalues should ALWAYS use the setter, it makes no sense otherwise.

Arun Chandrasekaran <aruncxy gmail.com> writes:

On Thursday, 31 May 2018 at 01:49:42 UTC, DigitalDesigns wrote:
 https://dpaste.dzfl.pl/6c6e614b58ac

 The problem given in the list, is that a ref getter is used 
 when a setter does not exist. Why have a setter then?

 [...]

Please report issues at https://issues.dlang.org otherwise it 
will be lost in forums/emails. Whereas if you have the bugzilla 
ID, it would be a reference to discuss upon.

Neia Neutuladh <neia ikeran.org> writes:

On Thursday, 31 May 2018 at 01:49:42 UTC, DigitalDesigns wrote:
 Using setters, we might want to trigger an event when the value 
 changes. But since the getter is used and can modify the event 
 won't be triggered.

 This is a bad design.

Here's similar bad design:

---
class Int
{
   public int value;
}
class Holder
{
   private Int _prop = new Int(10);
   public Int prop() { return _prop; }
   public void prop(Int value)
   {
     assert(value.value == 10);
     _prop = value;
   }
}
Holder a = new Holder();
a.prop().value = 9;
---

I broke an invariant and there's no warning about it. D's 
properties are indeed broken!


-> vs . and missed a couple pointers and it's C++. No, wait, I 
think it's Dart. Or maybe a new version of Javascript? I can't 
keep up with ECMA.

The problem is that mutable getters and validating setters don't 
mix. This is easy enough to fix in your code: change `T getter()` 
to `const(T) getter()`.

Mike Franklin <slavo5150 yahoo.com> writes:

On Thursday, 31 May 2018 at 01:49:42 UTC, DigitalDesigns wrote:
 https://dpaste.dzfl.pl/6c6e614b58ac

 The problem given in the list, is that a ref getter is used 
 when a setter does not exist. Why have a setter then?

 One problem is that if the setter has different behavior than 
 the getter there will be problems.

 The other problem is that += modifies the value.

 normally getters are thought to be immutable in the since that 
 they just return a value.

 but

 a += will modify what a points to.

 Using setters, we might want to trigger an event when the value 
 changes. But since the getter is used and can modify the event 
 won't be triggered.

 This is a bad design.

 any modifying operator should call the setter. This is 
 precisely what "set mean".


 a += b is suppose to be syntactic sugar for a = a + b, yet we 
 get different behavior. In one case only a getter is called and 
 in the second case the getter and then the setter.

 How D currently handles this is wrong and error prone. Either 
 depreciate the use of op assignments using properties or fix 
 it! lvalues should ALWAYS use the setter, it makes no sense 
 otherwise.

In case you're not already aware, there is a DIP in progress to 
remedy this issue:  https://github.com/dlang/DIPs/pull/97.  A few 
bugs have already been filed on this, and the DIP intends to 
address that.  If you have anything to add, please voice your 
thoughts in the DIP's PR.

Mike