Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
From: Rob Tompkins <chtompki@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [lang] Appetite for new method StringUtils.toCamelCase(String
 str, char delimiter, boolean capitalizeFirstLetter)
Date: Thu, 1 Jun 2017 11:02:02 -0400
References: <910772F4-308B-4EAB-BB97-040628075D7A@gmail.com>
 <CACZkXPx5FObHrcCjjfOvP5Y0Y8ZU+hqB1cbvT_EYYn0aA7+Zew@mail.gmail.com>
 <A501C14F-80C5-43CC-9FF4-5F84E0184B7F@gmail.com>
 <CACZkXPxeiGD7JMc_KJRrOaZ3x_U3LZKVW+xT2qh_5E53haCJmA@mail.gmail.com>
 <CABeJX=2+khBB7C1ud3SdcdoujXO2bXBaDz2v4X9WifcmmeU91g@mail.gmail.com>
 <MWHPR06MB3310E38BA720471E86BB5A96E7F60@MWHPR06MB3310.namprd06.prod.outlook.com>
To: Commons Developers List <dev@commons.apache.org>
In-Reply-To: <MWHPR06MB3310E38BA720471E86BB5A96E7F60@MWHPR06MB3310.namprd06.prod.outlook.com>
Message-Id: <51B56C91-A6F6-46D0-A083-1946A7B8B997@gmail.com>
archived-at: Thu, 01 Jun 2017 15:02:16 -0000


> On Jun 1, 2017, at 10:58 AM, Roger Whitcomb =
<Roger.Whitcomb@actian.com> wrote:
>=20
> I have a similar method in our code -- the use case is to take user =
input (plain English field names, for instance) and turn it into =
variable names for DTOs (or similar).
>=20
> Another use we have for it is taking Java format ENUM_NAMES and =
turning them into camelCaseVariableNames for things like dynamic =
property sheets.

This is quite similar to what we are doing as well.

and @Gary - I like both ideas, WordUtils or CamelCaseUtils.

-Rob

>=20
> ~Roger Whitcomb
>=20
> -----Original Message-----
> From: Duncan Jones [mailto:duncan@wortharead.com]=20
> Sent: Thursday, June 01, 2017 7:32 AM
> To: Commons Developers List <dev@commons.apache.org>
> Subject: Re: [lang] Appetite for new method =
StringUtils.toCamelCase(String str, char delimiter, boolean =
capitalizeFirstLetter)
>=20
> On Thu, 1 Jun 2017 at 15:27, Gary Gregory <garydgregory@gmail.com> =
wrote:
>=20
>> IMO camel casing is all about words so [text] WordUtils. But why not=20=

>> have a CamelCaseUtils instead?
>>=20
>> Gary
>=20
>=20
> +1. IMO it belongs in TEXT (if anywhere) and we should avoid classes=20=

> +with
> static methods.
>=20
> Per our other conservation about case conversions, we should carefully =
specify whether this uses upper- or title-case and how it behaves in =
different locales.
>=20
> OOI, what is your real world use case for this?
>=20
> Duncan
>=20
>=20
>>=20
>> On Jun 1, 2017 7:14 AM, "Rob Tompkins" <chtompki@gmail.com> wrote:
>>=20
>>>=20
>>>> On Jun 1, 2017, at 10:11 AM, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>>>=20
>>>> Isn't this kind of stuff or anything camel case supposed to be in
>> [text]
>>>=20
>>> I=E2=80=99m ok with that path as well. It feels like it=E2=80=99s on =
the line=20
>>> between the two components. Either way, it sounds like you=E2=80=99re =
not=20
>>> opposed to adding
>> it
>>> to a component.
>>>=20
>>> Should it be TextUtils.toCamelCase(String str, char delimiter,=20
>>> boolean capitalizeFirstLetter), or WordUtils maybe, if we were to=20
>>> put it in
>> [text]?
>>>=20
>>> -Rob
>>>=20
>>>> these days?
>>>>=20
>>>> Gary
>>>>=20
>>>> On Jun 1, 2017 7:03 AM, "Rob Tompkins" <chtompki@gmail.com> wrote:
>>>>=20
>>>>> Hello all,
>>>>>=20
>>>>> Folks at my day job have a method that takes in a space delimited
>> String
>>>>> (or arbitrarily delimited string for that matter), and returns a=20=

>>>>> camel cased string. Is there any reason that this shouldn=E2=80=99t =
be in
>>> StringUtils? It
>>>>> feels reasonable to me. What are folks thoughts?
>>>>>=20
>>>>> Cheers,
>>>>> -Rob
>>>>> -----------------------------------------------------------------
>>>>> ---- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>=20
>>>>>=20
>>>=20
>>>=20
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>=20
>>>=20
>>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org