I would think it's possible to hide that "configuration" from the user such that the implementation can only be reconfigured via extension. But I'm not in love with the configurable base class either way. It was convenient to have the common functionality in one place, but it's not a big deal to handle that differently.
The tradeoff in having the Cases be pure functions is that it makes it more difficult for a user to extend them with additional functionality. And to me the need for extension is apparent even when just looking at the 4 basic cases. Two of them are character delimited, and 2 of them are uppercase delimited. There's two bits of shared functionality just in the 4 most basic cases. Back to the exception topic, I don't think the tokens "my" "component" and "1" can be formatted in PascalCase in a way that they could be parsed back out into 3 tokens. So the question is less about whether it's possible to format them and more about whether the API should format output that cannot be parsed back into the same input. I think it makes sense to enforce that consistency, or at the very least allow the user to enable it? On Wed, Aug 9, 2023, 9:14 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > On Wed, Aug 9, 2023 at 11:36 PM Daniel Watson <dcwatso...@gmail.com> > wrote: > > > > Meant to add... > > > > The reason I would favor exceptions is that the underlying implementation > > can be easily customized. If the user needs to allow non alphanumeric > > characters there is a boolean flag in the underlying abstract class > > (AbstractConfigurableCase) that will simply turn that validation off. > > This is another point, but customizability is a bug, not a feature. I > don't want to guess what the method might be doing based on what flag > was set where. I want camel case to mean one thing and one thing only. > Ditto snake case, pascal case, and any other formats. Possibly there's > a reason to add additional subclasses, but the > CamelCase/SnakeCase/KebabCase classes should not emit different > strings depending on how they're configured. The public API should be > a pure function, not an object. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
