AW: [LANG] Thoughts about Lang 4.0

[jhm]

> For the tuple classes, it would be possible to make an entire tuples
> library. Might be handy to generate code for it as it'd be useful to
> support tuples up to, say, 22 fields (Scala has tuple classes and
> anonymous function classes up to 22 arguments, for example). See <
> https://www.scala-lang.org/api/current/scala/Tuple22.html>.

One benefit of having an ASF commons "tuple library" is  it's from the ASF.
I am not joking. An ASF library promisses to have a community and a life cycle 
you can 
precognize. In contrast a "simple" github library is just a peace of code.



> If we go to Java 8 as a base line (which would make sense), we don't
> need a commons-date library anymore, though if we did, it would be
> based on the java.time API instead. Not sure which functionality would
> be useful here.

I think converter functions between java.util.Date and java.time could be 
helpful.
Think of "old" modules of your application (maybe 3rd party libs) which require 
the one 
and other parts which require the other.


Jan


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

Jenkins build is back to normal : Commons-Compress » Apache Commons Compress #276

[Apache Jenkins Server]

See 



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

[RESULT][VOTE][LAZY] Move commons-imaging to git

[Rob Tompkins]

Hello all,

This vote passes with the following (in order of appearance):

Gary Gregory: +1
Amey Jadiye: +1 (non-binding)
Damjan Jovanovic: +1
Dave Brosius: +1

With no down votes I will begin the process of migrating to git.

Having not gone through this process before, what must I do to accomplish the 
task. My first thought is to open a jira with INFRA and go from there. But, I 
recall hearing from folks that one must be a PMC member to accomplish this 
task, so I may need to ask for assistance.

Cheers,
-Rob

> On May 18, 2017, at 1:22 PM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> I would like to propose that we move commons-imaging to git in hopes of doing 
> that before the potential of releasing a 1.0. I figure that it would be an 
> easier migration with only a trunk to manage in getting it over there.
> 
> For this reason I’m calling a vote by lazy consensus for moving Apache 
> Commons Imaging to the git version control system. This vote will pass if 
> nobody objects within the next 72 hours, i.e. after May 21, 2017 1800 (UTC).
> 
> Cheers,
> -Rob
> 
> 


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

Re: [TEXT] How do we want to handle case conversions?

[Gary Gregory]

On May 21, 2017 10:56 PM, "Duncan Jones"  wrote:


> On 21 May 2017, at 19:43, Gary Gregory  wrote:
>
> Pardon the obvious but what is missing from methods like
> https://docs.oracle.com/javase/7/docs/api/java/lang/
Character.html#isLowerCase(char)
>
> Gary


The WordUtils methods turn sentences into title case, which Java’s core
libraries don’t offer. In fact, the core libraries make doing
locale-sensitive title case conversions very difficult (see
http://stackoverflow.com/questions/7360996/unicode-
correct-title-case-in-java for example).

Doing title casing correctly is quite a subtle art. We don’t even do it
correctly for English at the moment, which would normally capitalise “The
Life of Reilly” rather than “The Life Of Reilly”. Other languages have
completely different conventions or additional complexities.


I see. So the hard part is coming up with the rules.

Aside from that I could see creating an instance of a class
"TitleCaseConverter" or some such with a Locale through a factory method.
The factory can decide whether or not to create a Locale specific subclass.
Maybe there are general rules that could be implemented in the parent class
or even driven of a locale specific properties file... TBD ;-)

Gary



>
> On May 21, 2017 5:06 AM, "Duncan Jones"  wrote:
>
>> Hi everyone,
>>
>> I’ve found some time to continue breaking WordUtils into separate classes
>> (eschewing the “big collection of static methods” approach). However, as
I
>> read more about case handling in Unicode, I realise how simplistic the
>> WordUtils methods are and how complex a full solution would need to be.
>>
>> Section 5.18 of the Unicode specification [1] describes these
>> complexities. The mains ones that bother me are:
>>
>> 1. Title case conversions vary widely between different locales and
>> languages. I’m not clear whether any locale is satisfied by the current
>> simplistic implementation in WordUtils.capitalize(str). Supporting this
>> correctly would be a serious challenge.
>>
>> 2. All types of case conversion may vary depending upon context/locale.
>> There are examples provided in [1] where the outcome is different in a
>> Turkish locale or if the letter in question is followed by another or
not.
>>
>> Does anyone have a suggestion for how to move forward with this work? I
>> see three options: 1] Admit defeat and avoid the case conversion mess
>> entirely. 2] Mimic the existing functionality, but document the
>> limitations. 3] Attempt to deliver a locale-dependent version, perhaps
>> still with limitations (or for certain languages).
>>
>> I’m leaning towards 2, perhaps even calling the classes “SimpleX…”.
>>
>> Thanks,
>> Duncan
>>
>>
>> [1] http://www.unicode.org/versions/Unicode9.0.0/ch05.pdf
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>


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