You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Luca Burgazzoli <lb...@gmail.com> on 2016/10/14 12:11:32 UTC
Enhance ObjectHelper's after/before/between
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
Re: Enhance ObjectHelper's after/before/between
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Oct 14, 2016 at 2:38 PM, Antonin Stefanutti
<an...@stefanutti.fr> wrote:
>
>> On 14 Oct 2016, at 14:35, Luca Burgazzoli <lb...@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.
>
I think we didnt have string helper in the start, and most such util
methods was added on object helper.
>> ---
>> Luca Burgazzoli
>>
>>
>> On Fri, Oct 14, 2016 at 2:25 PM, Antonin Stefanutti
>> <an...@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 <lb...@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
>>>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Enhance ObjectHelper's after/before/between
Posted by Luca Burgazzoli <lb...@gmail.com>.
I've logged two JIRA:
- https://issues.apache.org/jira/browse/CAMEL-10389 --> Move some
function to Stringhelper (target 2.19)
- https://issues.apache.org/jira/browse/CAMEL-10390 --> Enhance
before/after/between (target 2.18.1)
---
Luca Burgazzoli
On Fri, Oct 14, 2016 at 2:38 PM, Antonin Stefanutti
<an...@stefanutti.fr> wrote:
>
>> On 14 Oct 2016, at 14:35, Luca Burgazzoli <lb...@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
>> <an...@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 <lb...@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
>>>
>
Re: Enhance ObjectHelper's after/before/between
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
> On 14 Oct 2016, at 14:35, Luca Burgazzoli <lb...@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
> <an...@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 <lb...@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
>>
Re: Enhance ObjectHelper's after/before/between
Posted by Luca Burgazzoli <lb...@gmail.com>.
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
<an...@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 <lb...@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
>
Re: Enhance ObjectHelper's after/before/between
Posted by Antonin Stefanutti <an...@stefanutti.fr>.
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 <lb...@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