> On 14 Oct 2016, at 14:35, Luca Burgazzoli <lburgazz...@gmail.com> wrote:
>
> 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.
I didn’t dare to propose you that but that’s exactly what I had in mind ;-)
That being said, I don’t have the historic being this so there may be a good
reason.
> ---
> 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
>>
