I've incorporated some of the recommendations from this thread into the
Case api. Have a couple additional things to ask for thoughts on...
1) The current caseutils is just in org.apache.commons.text, but given that
this is multiple classes, I put the code into
"org.apache.commons.text.cases" ("case" is reserved). Thoughts?
2) Although I don't propose removing/deprecating the existing CaseUtils,
does it make sense to try and test against the use cases that overlap i.e.
validating that they produce the same output? Or is that just an
unnecessary link?
- Dan
On Fri, Aug 11, 2023 at 11:31 AM Daniel Watson <dcwatso...@gmail.com> wrote:
> 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
>> > >
>> > >
>> >
>>
>
