An option would be to move before/after/between in StringHelper and
wrapping them in ObjectHelper with @Deprecated annotation, the
proposed new methods should go straight to StringHelper.
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:25 PM, Antonin Stefanutti
<anto...@stefanutti.fr> wrote:
> Hi Luca,
>
> Make sense to me. As I refactored Camel CDI with Java 8 in Camel 2.18.0, I
> found using Optional as return type of internal util methods quite useful in
> term of client conciseness / readability compared to null handling.
>
> I’m wondering whether that should be added to StringHelper instead of
> ObjectHelper though the existing methods are in the later so probably a
> trade-off between consistency / locality and relevancy.
>
> Antonin
>
>> On 14 Oct 2016, at 14:11, Luca Burgazzoli <lburgazz...@gmail.com> wrote:
>>
>> Hello,
>>
>> I've sometime had the need to find a string after a separator, lookup
>> an object based on the result value and then use it to process
>> something, like:
>>
>> String after = ObjectHelper.after(key, ":");
>> if (after != null) {
>> MyStuff s = cache.get(after)
>> if (s != null) {
>> s.doSomething(exchange)
>> }
>> }
>>
>>
>> So I wonder whether it makes sense to add a 'fluent' variant to these
>> functions to impement such pattern, like:
>>
>> <T> Optional<T> after(String value, String delimiter,
>> Function<String, T> function)
>>
>>
>> The we could do something like:
>>
>> ObjectHelper.after(key, ":", cache::get).ifPresent(s ->
>> s.doSomething(exchange));
>>
>>
>> Make sense ?
>>
>>
>> ---
>> Luca Burgazzoli
>
