Minor correction below.
On 9/6/2018 1:04 PM, Adam Petcher wrote:
In the latest webrev, I changed it so there is a single static
NamedGroupFunctions of each type, and the NamedGroup is passed in as
the first argument to each method that requires it (rather than
being a member of NamedGroupFunctions).
After the re-org, I guess you can put the inner classes in NamedGroup
enum and declare them as private? The getFunctions() method may be
unnecessary then.
I don't know if that works, exactly, due to the fact that I can't
reference static enum members in the body of an enum constructor. How
about this alternative? I can move the NamedGroup enum and all the
NamedGroupFunction classes into a separate class (in a separate file)
called NamedGroups. Then all the NamedGroupFunction classes can be
private in this class, but the NamedGroup enum can still have package
access. I would prefer to leave the getFunctions() method of
NamedGroup (and keep it private) because the functions object may be
missing and the Optional return type of getFunctions() forces me to
deal with this when I call it from within NamedGroup.
Actually, it does work. I just have to move the static members of each
NamedGroupFunctions subclass into its subclass (e.g. make them
singletons). Still, I like my proposed alternative better, because it
allows us to simplify SupportedGroupsExtension. Let me know if you have
a preference.
