> 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 >>