Define default "get" semantics

[DartBot]

This issue was originally filed by @seaneagan

---

One very common use case for setters is to validate field values. Currently to do this, one must create a companion private field, set this field in the public setter if validation passes, and define a public getter which returns the private field like so:

class A {
  num _x = 0;
  num get x() => _x;
  set x(num v) {
    if(v > 5) throw new Exception();
    _x = v;
  }
}

This could be shortened drastically by specifying that if an accessor only defines a "set" handler, then anytime the "set" completes without throwing an exception, the passed value of the field is stored, and returned for subsequent "get"s. Then the above could be shortened to just:

class A {
  set x(num v) {
    if(v > 5) throw new Exception();
  }
}

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Area-Language, Triaged labels.

[gbracha]

It's unlikely we'll define syntactic sugar that i so narrowly focused. These tailor-made rules tend to explode in one's face as the unforeseen interactions mount.

---

Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement label.

[gbracha]

Issue #72 has been merged into this issue.

[DartBot]

This comment was originally written by @seaneagan

---

But currently defining only a setter causes gets to throw, the proposed semantics seem more useful than that.

However, the proposed semantics could be made more generic by allowing the setter to return the value which they want to later be returned by the getter. Setter return types would no longer cause warnings when non-void, but rather when not assignable to the setter argument type, as is the case with getter return types.

Basically this would be a way to allow omission of getters when a field's value can be determined at the time of the previous "set". Such a field's value would be initialized to null of course. For example:

class A {
  int ySetCount = 0;
  set x(num v) => Math.max(v, 5);
  set y(v) {
    ySetCount++;
    return v;
  }
}

[DartBot]

This comment was originally written by paul.bjorks...@gmail.com

---

This idea is great. I would like to extend the syntax as well. How many times has a program been written that uses direct variable access, then much later to find out that you need to do some sort of validation of the value before a get/set? I have been a part of a few projects that have had this problem. Refactoring all the code in the project can be a hassle. Even worse, you can't just tell customers that they need to change all their software, that is not a good business practice. Sure you can train your developers with the best practices, but someone will eventually break the rules for a quick fix or a dirty patch just to get the job done.

My proposal is to allow getters and setters to use the same name as the variable. Also, allow a default getter/setter if one is not defined (essentially direct access)

You start with:

class {
  // Variables
  var x, y;
}

After, even if the code is used elsewhere, you can change to:

class {
  // Variables
  int x, y, _defaultY;
  
  // Getters and Setters
  set x(v) {
    if (_isValidXVal(v)) {
      x=v;
    } else {
      throw Exception();
    }
  }
  get y() => _isValidXVal(x) ? y : _defaultY;
  
  // Methods
  bool _isValidXVal(x) {
    return x > 0
  }
}

This change will be seamless to the client, all they will notice is when the values are not valid, which they would need to fix anyway.

I do know that it may be difficult to develop this functionality because of what could cause recursion, but that issue could be solved by creating a special keyword or operator to access the actual varaible inside getters and setters. In Fantom (a JVM language) they use & to access a variable directly within getters and setters. If there was a special name it could be 'it':

class {
  // Variables
  int x, y, _defaultY;
  
  // Getters and Setters
  set x(v) {
    if (_isValidXVal(v)) {
      it=v;
    } else {
      throw Exception();
    }
  }
  get y() => _isValidXVal(x) ? it : _defaultY;
  
  // Methods
  bool _isValidXVal(x) {
    return x > 0
  }
}

Any comments?

[DartBot]

This comment was originally written by jat@google.com

---

So the only thing you are suggesting that is different from what Dart already implements, is to name the underlying field the same as the getter/setters. I don't see it as a big deal make this change by making the field private and referencing it in the getters/setters.

[DartBot]

This comment was originally written by marai...@gmail.com

---

In the above example:
class A {
  set x(num v) {
    if(v > 5) throw new Exception();
  }
}

Herein you have an ambiguity.. You are assuming you ALWAYS want writable properties/fields too be readable. You would be excluding a large class of reflective tools that build off getter/setter symantics. Not that dart has reflection just yet. Even without this situation, it's possible that the code wants you to write to one place and read from some place else, otherwise there is a violation of an assumption or convention (perhaps to enforce deprecation)

While I'd personally be interested in subtly altering the private, package, public, read-only, write-only, read-write (with possible aspect-injected filters), I'm not in favor of this particular recommendation.

As for the second recommendation of allowing the get/set methods to have the same name as the field.. I have all sorts of not-fully-thought-out worries about this. Memories of subtle problems with perl colliding data-types with common names come to mind.. bad bad bad. If nothing else, it opens pandoras box to future equally nasty colliding namespaces, then one day, you want reflection/serialization and go.. oh crap.

[DartBot]

This comment was originally written by @seaneagan

---

@7: Yes, I think writable fields should ALWAYS be readable. Do you have any concrete use cases for write-only fields ? Google's Dart style guide (http://www.dartlang.org/articles/style-guide/) doesn't take quite as hard of a line when it says:

  Usually have a corresponding getter. It feels weird for users to have state that they can modify but not see. (The converse is not true; it's fine to have getters that don't have setters.)

I don't see why reflective tools would require write-only fields.

You often do write to a setter, and then read from some other getter, but in those cases you can also read from the same-named getter.

I think it is at least weird enough to justify a compiler warning if not default "get" semantics.

[DartBot]

This comment was originally written by le...@google.com

---

@5 -- Another problem with your syntax is that other methods in the class will want to refer to the property or field, and they might want its validation or they might want to bypass it; there isn't a sensible default.

C# has default setters/getters which are nice for when you want something to be publicly gettable and privately settable, but they don't get you much else beyond what DART has. In my experience virtually every property known to man is backed by a field of the same type and the same name with an _ preceding it. It should be possible to optimize this and get rid of all the redundancy.

What if:

1. A getter or setter, by mentioning a field sharing its name preceded by one or more underscores, could cause it to be assumed into existence if it wasn't already declared. This would basically never be a typo, and everyone wants the same thing here, and if they don't they could still declare the field.

2. A default getter/setter could be specified succinctly that simply read or wrote this field.

So Sean's example becomes:

class A {
  num get x();
  set x(num v) {
    if(v > 5) throw new Exception();
    _x = v;
  }
}

And Paul's:

class {
  // Variables
  int _defaultY;
  
  // Getters and Setters
  set x(v) {
    if (_isValidXVal(v)) {
      _x=v;
    } else {
      throw Exception();
    }
  }
  get x();
  set y();
  get y() => _isValidXVal(x) ? _y : _defaultY;
  
  // Methods
  bool _isValidXVal(x) {
    return x > 0
  }
}

It's still a little verbose because you still have to name every property twice and declare its type twice. With a more C#-like syntax this could be:

class A {
  num x {
    get;
    set(num v) {
      if(v > 5) throw new Exception();
      _x = v;
    }
  }
}

class {
  // Variables
  int _defaultY;
  
  // Getters and Setters
  var x {
    get;
    set(v) {
      if (_isValidXVal(v)) {
        _x=v;
      } else {
        throw Exception();
      }
    }
  }
  var y { set; get => _isValidXVal(x) ? _y : _defaultY;}
  
  // Methods
  bool _isValidXVal(x) {
    return x > 0
  }
}

Which would look like a bigger improvement if you used longer names and types.

[DartBot]

This comment was originally written by @seaneagan

---

@9: I like C#'s getter/setter syntax as well. C# also lets you omit the parameter lists (including parentheses) for getters and setters with an implicit "value" ("v" would be better ?) setter parameter. Combining this with your syntax:

class A {
  num x {
    get;
    set {
      if(value > 5) throw new Exception();
      _x = value;
    }
  }
}

Regarding the implicitly created parallel private member, I like that too, the main issue I see is if the original member is already private, then the implicit parallel member would be prefixed with two underscores? Could just require explicitly creating the parallel member in that case. I think a better option though might be just using the return type of the setter as the value to later be returned by the getter:

class A {
  num x {
    get;
    set {
      if(value > 5) throw new Exception();
      return value;
    }
  }
}

another syntax for this, less different than the current syntax, would be to have the return type of the setter be "get":

class A {
  get set x(num v) {
    if(v > 5) throw new Exception();
    return v;
  }
}

[DartBot]

This comment was originally written by @seaneagan

---

Going in the other direction of default "set" semantics, maybe the getter could receive a parameter with type "set" which corresponds to the value the member was previously set to:

class A {
  String get name(set v) => v === null ? "NA" : v;
}

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Removed triage1 label.
Added WontFix label.

[gbracha]

The debate on getters/setters has raged on for a long time, with varying proposals. Views differ radically. We are not going to make big changes in this area.