Imported From: https://issues.scala-lang.org/browse/SI-2215?orig=1
Reporter: Reuben Firmin (reubenfirmin)

@lrytz said:
This is on hold until a good & feasible solution is proposed (http://www.nabble.com/-scala--properties---bean-properties-td25028167.html)

Another idea is to define the validation logic in a separate private method, e.g.

class A {
  @BeanProperty @preGet(preHoovesGet) @preSet(preHoovesSet) var hooves = 0
  private def preHoovesSet(h: Int) = {
    require(h < 5)
    h
  }
  private def preHoovesGet(h: Int) = {
    log("reading hooves: "+ h)
    h
  }
}

the generated getter / setter would then have the form (hooves denotes the actual field)

def hooves: Int = preHoovesGet(`hooves`)
def hooves_=(h: Int) { `hooves` = preHoovesSet(h) }

ddekany said:
How about simply supporting @BeanProperty on methods? If the annotated method looks like def someName: SomeType then it generates def getSomeName() = someName, and if the annotated method looks like def someName_=(val: SomeType): Unit then it generates def setSomeName(val: SomeType) { someName = val }. This would work even if there is no var that backs both methods, that is, for calculated properties. Annotated methods that doesn't follow any of the above patterns should cause a compilation error. (Later this could be extended to support indexed properties as well.)

A drawback is that it's a bit verbose in this common case (two @BeanProperty-es):

private _someName: SomeType
@BeanProperty def someName = _someName
@BeanProperty def someName_=(val: SomeType) {
  /* do some extra things here */
  _someName = val
}

But even this is better that we have now. To improve this further, there should be a standard way of naming those private vars (like _${propertyName}), because then one could just annotate the private var with @BeanProperty, and it could deduce the method names from the var name. If the var name doesn't follow the proper format or there's no matching method then that should be a compilation error, rather than a silent no-op.