Getter and setter naming

[PeterJohnson]

Forking from the conversation in #7821.

Java records generate x() accessors (there's no x(value) setters because records are immutable).

Will entry-level (middle school level) students understand how Java records work? Will they understand x() better than getX()? Will they understand why it's x() and not just x?

More generally, currently WPILib uses getX() and setX(value). Would it make sense more broadly to change to x() getter and x(value) setter naming (or x() getter and setX(value))? The getX/setX naming is very common historically in Java; there are a few standard library classes that use just x() and x(value) but the extra get and set prefix may make usage easier to understand for brand-new programmers?

Unfortunately Java as a language doesn't support properties, which would be the cleanest solution to this by allowing variable-like access. Python does, however, and we might want to consider that, although it may be challenging to generate PyBind wrappers that do that without a lot of custom work.

Relatedly, in cases where we want additional getters for unit types, how should those be named? Setters can be overloaded if desired, but getters need unique naming. Should they both be uniquely named?

[virtuald]

It's trivial to manually add properties in python, and we already do this for some of the geometry classes. For unit-specific properties, the convention I've been using is the 'normal' accessor is the SI unit, and then other properties are suffixed with the converted unit.

Here's how rectangle 2d has extra properties/unit methods: https://github.com/robotpy/mostrobotpy/blob/main/subprojects/robotpy-wpimath/gen/geometry/Rectangle2d.yml#L33. The resulting docs are at https://robotpy.readthedocs.io/projects/robotpy/en/stable/wpimath.geometry/Rectangle2d.html#wpimath.geometry.Rectangle2d.xwidth

[crueter]

Copying my thoughts from the issue:

The most intuitive solution would be to use a public member variable, a la x = ... and access it via x. This of course doesn't let you do anything custom in your setters.

The ideal solution then would be allowing that syntax but still with custom setter/getter functionality. The best example is Qt (C++) which lets you define a "property" as such:

private:
    int m_value = 0;
    Q_PROPERTY(value int READ value WRITE setValue)

public:
    int value() const { return m_value; }
    void setValue(const int newValue) { m_value = newValue; } // and any custom stuff can be done here

And then in QML, which can access C++ containers:

customClass.value = 10
console.log(customClass.value)

Of course this isn't really easy to implement. In C++ you could probably do some weird stuff with operator int() const etc. and operator=(), which would be cumbersome and most likely not worth the extra effort--God forbid anything of that nature in Java, barring a major addition to the language to support that.

In my experience teaching brand-new programmers, most seem to pretty equally understand both getX() and x(). It's not really intuitive when learning OOP anyway, because like I said, either way they're expecting it to be class.x = ... and class.x. If anything they seem to expect to NOT use the get prefix since it's a little further away from the procedural variables they're used to.

Additionally, depending on where this discussion ends up, another discussion about what method casing to use would be good--particularly with C++ which has three competing standards that are used in all sorts of different libraries, and in maintaining parity between C++, Java, and Python.

[PeterJohnson]

Regarding method casing, the C++ user base is small enough I'm not sure it matters much to match the others. Matching Java and Python has been maybe sort of nice, but it doesn't seem like a big barrier if they're different, particularly if Python is using properties while Java needs getter/setters, there's bigger changes at play.

There is definitely an argument to change both C++ and Python to snake case, but it's going to be a fairly large amount of effort to make a change, especially across all docs and examples. Someone will need to volunteer to take that on if it's going to happen, as the current dev team doesn't have the bandwidth to do it.

[SamCarlberg]

Relatedly, in cases where we want additional getters for unit types, how should those be named? Setters can be overloaded if desired, but getters need unique naming. Should they both be uniquely named?

I think what wpimath currently does, where the methods that return raw doubles have the unit name baked into the method name (eg double getPositionMeters()) would be ideal. The measure versions could drop the unit name (eg Distance getPosition()), or append Measure to the name (eg Distance getPositionMeasure())