Priority in fluent properties

[yloiseau]

We introduced fluent properties, that allows to call setValue(v) as just value(v) and getValue() or isValue() as value(). However, if a value() method exists, the property is called instead.

For instance, given:

public class A {

  public String getValue() {
    return "getter";
  }

  public Integer value() {
    return 42;
  }
}

and

module Test

function main = |args| {
  println(A(): value())
}

javac A.java && golo golo --files test.golo will print getter, while 42 is expected

[danielpetisme]

Not sure it's a bug .... The current method resolution looks in order for:

• first a property. Given a property name, the property finder looks for (in order) :
  • getName
  • isName
  • setName
• then for a method. Given a property name, it looks for a method named name + number of arguments required.
• finally look for a method in the class augmentation

So basically it's the normal behavior so now 2 options, either we say it's not a bug and we document the Method finding algo. or we modify the algo.

For me current behavior sounds wise because the classic Java methods (the explicit ones) are used in the first place.

[yloiseau]

I think it qualifies as a bug, since in my example, there is no way to call the value() method.

[danielpetisme]

What would be the correct order? Method, property then augmentation ?

[yloiseau]

I think so. IMO we should involve the "magic" only when "normal" method fails. Don't know if others agree @Artpej @jponge

[yloiseau]

I'd say it can be considered bad design to have both a "bean" interface and a fluent one (as in my example) but it could be useful (e.g. for framework compatibility). Anyway, we should not make such objects unusable.