If no instance of Thing1Case can be reconfigured, then that holds true, right? The fact that it extends something like DelimitedCase doesn't break the spec I wouldn't think?
On Fri, Aug 11, 2023, 11:23 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Hm, I too, would expect Thing1Case to mean one thing and one thing only... > hence this specification exercise 😉 > > Gary > > On Wed, Aug 9, 2023, 9:52 PM Daniel Watson <dcwatso...@gmail.com> wrote: > > > 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 > > > > > > > > >
