Fix unseen Inner Class of Abstract Class

[olabusayoT]

• Scala 3.3.5 complains about not seeing the inner class Value of Enum, so we refactor to make Value a trait of an Enum companion object

DAFFODIL-2975

[mbeckerle]

+1

[stevedlawrence]

+1, maybe some minor changes to simplify things?

[stevedlawrence]

The special case for CalendarFirstDayOfWeek feels a bit too specific for this generic trait. Maybe this is an exception that the property generator should do? Thinkkng about my above question, if the type parameter really isn't needed, maybe Enum.Value just becomes different variants of toString implementations for different kinds of enums, e.g.:

trait EnumValue extends EnumValueBase {
  override def toString = {
    /* current implementation with initial lower case unlessall upper
        case, without calendar first day of week exception */
  }
}
trait EnumValueSimple extends EnumValueBase {
  override def toString = getNameFromClass(this)
}

Most classes would just look like this to get the normal behavior:

sealed trait SeparatorSuppressionPolicy extends EnumValue

But CalendarFirstDayOfWeek would look like this:

sealed trait CalendarFirstDayOfWeek extends EnumValueSimple

I don't think we should make this change as partof this PR, modifying the generator for this one exception probably isn't worth it, but it might be worth opening a new cleanup ticket--this would probably be a good beginner issue to add new trait and modify the property generator to extends a different class depending on some exception list.

[olabusayoT]

Created DAFFODIL-2983

[stevedlawrence]

Do we need the type parameter? To use the new Enum.Value a trait now needs to duplicate it's own trait name without much gain, I think?

The only thing the Value trait really provides now is a default implementation of the toString function, which doesn't depend on the type parameter.

I also wonder if instead of putting it in a Enum object, what if we just call it EnumValue? Similar to how Enum, EnumBase, EnumValueBase are their own things?

Then this just becomes:

sealed trait Foo extends EnumValue
object Foo extends Enum[Foo] {
  ...
}

Seems a bit cleaner and I think doesn't lose any type safety or functionality?

[stevedlawrence]

Maybe this is the reason for needing the type parameter in Enum.Value, mentioned in a previous comment? Though, could this be changed to this:

var representation: Representation = Representation.Text

Representation is a trait that all representation enum values extend so I think this type is still accurate? It's maybe less clear that Representation is an enumeration value, but it's definitely cleaner. In fact, I think this is the only place where we use Foo.Value to reference our custom enum types since this is the only one you had to change.