[epilogue] Autogenerate nicer data names by default, not just raw element names

[SamCarlberg]

eg "getFoo()" will now be logged as "Foo", or "m_leftMotor" as "Left Motor"

It is now a compilation error to reuse the same logged name for multiple elements (since whatever is declared last would overwrite anything logged before it)

Do not log record fields (just use the accessors). This also fixes an issue where records could never be logged due to identical member and accessor names

Also skips toString, hashCode, and clone methods when generating loggers

[oh-yes-0-fps]

I believe changing the case of the field names is worse than logging the raw names. It could make it harder to quickly search for things in the advantage scope search bar. Removing suffixes isn't a terrible idea though.

[BR88C]

Could there be an option to opt out of the renaming behavior globally, or at the very least, an option to opt out when annotating a class with @Logged? I could see the desire from teams to use either behavior. While this solution does rename fields predictably, I could see it being confusing for some students as opposed to using the raw name. For what it's worth, I also believe that the existing name override when annotating a field or method individually was a sufficient solution.

[BR88C]

perhaps the old behavior can be retained via a global configuration setting?

From what I understand, since field names are fetched only during compilation, this would still have to be an option within the @Logged annotation that would propagate to subsequent annotated classes, and can't be specified in EpilogueConfiguration. This is what I meant when I said "global", which was misleading.

Upon further consideration I don't think propagation is viable, as there is a possibility for loggers needing both implementations of renamed fields and raw field names depending on where the user is opting out within the dependency tree of loggers, and if there is any overlap. So opting out (or opting in) per-class seems like the only alternative, though maybe there's a different solution I'm not seeing.

[katzuv]

I believe changing the case of the field names is worse than logging the raw names. It could make it harder to quickly search for things in the advantage scope search bar.

IIRC AdvantageScope uses fuzzy search, so it shouldn't be a problem.

[SamCarlberg]

From what I understand, since field names are fetched only during compilation, this would still have to be an option within the @Logged annotation that would propagate to subsequent annotated classes, and can't be specified in EpilogueConfiguration. This is what I meant when I said "global", which was misleading.

Yep, EpilogueConfiguration is a runtime-only thing. Any compilation configurations would need to be baked into the compile gradle task, such as by setting environment variables that the annotation process can read. Otherwise, it'd have to be configurable in the annotations themselves. Something like a an auto-name strategy like this could work, though it could only be configured on a per-class basis

@Logged(autoName = ELEMENT_NAME)
class D {
  double m_d; // logged as "m_d"

  double getD() { ... } // logged as "getD"
}

@Logged(autoName = FOR_HUMANS)
class I {
  int m_i; // logged as "I"

  int getI() { ... } // Also logged as "I" - name collision and compilation error
}

[spacey-sooty]

eg "getFoo()" will now be logged as "Get Foo", or "m_leftMotor" as "Left Motor"

I don't the idea of having "Get" in log entries, could this change getFoo() to Foo?

[SamCarlberg]

eg "getFoo()" will now be logged as "Get Foo", or "m_leftMotor" as "Left Motor"

I don't the idea of having "Get" in log entries, could this change getFoo() to Foo?

That's an error in my description - this does already remove the leading "get" from accessor methods. That's part of the reason why I made it an error to use the same name for multiple elements, otherwise a m_foo field and getFoo() accessor would both be logged as "Foo"