@Param support for enum

[Aleksey Shipilev]

On 06/25/2014 05:56 PM, Joe Kearney wrote:
> The particular thing about enums was that when you add more constants or
> rename you'll want those to be included in the parameter space, but
> without the double book-keeping of adding the constant name in @Param as
> well.
> 
> For booleans obviously the set of values won't change. As you described
> with enums, the set of possible boolean value is *small* and countable,
> so it can be done. I'd argue that (@Param boolean) is so simple to add
> and so obvious in what it means that it should be included.

There are basically three approaches:

 a) Everything should be explicit, and implicits are only there where
the alternative is inconvenient. That is, all @Params require explicit
default values, except for @Param(<enum>), which implicitly defaults to
the entire enumset. This is what we have now.
  + Consistent with only a single exception for out-of-band type
  - Requires specifying values for low-cardinality types

 b) Everything should be explicit, and implicits are only there where
the cardinality is low. That is, full enum set for @Param(<enum>), both
false/true for @Param(<boolean>). This is what being suggested by Joe.
  +- Consistency relies on definition of low-cardinality

 c) Everything may be implicit, and implicits include full domain for
low-cardinality types, and the default values for every other type.
  +- Consistency relies on definition of low-cardinality
  +- Better consistency across the types?

There is no obvious choice between either three. Maybe there is
something else I am overlooking; let's poll the audience!
  https://surveymonkey.com/s/J3Y8ZSX

Thanks,
-Aleksey.