Re: [Meta] gitlab error responses to mailing list
Ah, right, you're post here... I'm guessing that address is no longer valid or is one of those ".invalid" addresses services like Proton Mail uses... Gary On Sun, Aug 6, 2023, 10:04 AM Gary Gregory wrote: > I commons dev mailing list gets those. > > Gary > > On Sun, Aug 6, 2023, 9:29 AM Daniel Watson wrote: > >> Does anyone else get gitlab error messages in response to emails sent to >> this list (coming from supp...@cons3rt.com) ? The messages have no >> information as to the cause or resolution. Can't find any documentation >> about it on mailing list page. >> >
Re: [Meta] gitlab error responses to mailing list
I commons dev mailing list gets those. Gary On Sun, Aug 6, 2023, 9:29 AM Daniel Watson wrote: > Does anyone else get gitlab error messages in response to emails sent to > this list (coming from supp...@cons3rt.com) ? The messages have no > information as to the cause or resolution. Can't find any documentation > about it on mailing list page. >
[Meta] gitlab error responses to mailing list
Does anyone else get gitlab error messages in response to emails sent to this list (coming from supp...@cons3rt.com) ? The messages have no information as to the cause or resolution. Can't find any documentation about it on mailing list page.
Re: [commons-lang] Comments on new FunctionUtils / nested lambda feature
Yep that's correct. You cant get strong typing with varargs. Overloading
(yes, lazy) is how I handle it right now. I believe there's really one 2
methods that do anything significant to accomplish the goal, one that calls
a single nested function, and one that calls a single nested BiConsumer.
The rest essentially just chain on top of those.
More thought could certainly be given to it. There may be other related use
cases I haven't encountered. And I've yet to need nesting beyond 3 levels,
but would probaby offer methods that go a few levels beyond that, if only
because the cost is very little.
On Sun, Aug 6, 2023, 5:49 AM Rob Spoor wrote:
> I don't think that function chaining with varargs works, except with
> UnaryOperator. After all, the output type of the first must be
> compatible with the input type of the second, the output type of the
> second must be compatible with the input type of the third, etc.
>
> If you want to continue this way, the best option would be to have some
> overloads:
>
> Function nested(
> Function first,
> Function second)
> Function nested(
> Function first,
> Function second,
> R defaultValue)
> Function nested(
> Function first,
> Function second,
> Function third)
> Function nested(
> Function first,
> Function second,
> Function third,
> R defaultValue)
> ...
>
> If you're lazy you can delegate the overload with N functions to the
> overload with N-1 functions:
>
> Function nested(
> Function first,
> Function second,
> Function third,
> Function fourth,
> R defaultValue) {
>
> return nested(first, nested(second, third, fourth),
> defaultValue);
> }
>
>
> Rob
>
>
> On 06/08/2023 01:28, Gary Gregory wrote:
> > I'm not sure the "nested" example API is quite what it should be, because
> > the last argument is the default value, you cannot make the input
> functions
> > a vararg, which seems very limiting. I should be able to use the same API
> > whether I need to go 1, 2, or N functions deep. I'm saying the above
> > independently of whether this type of code should be in Lang.
> >
> > Gary
> >
> > On Sat, Aug 5, 2023, 9:27 AM Daniel Watson wrote:
> >
> >> Nice.
> >>
> >> Sounds like everyone is leaning towards "no". Would it be worth
> submitting
> >> a PR to include more usage examples - which I assume could also serve
> as a
> >> place to collect more feedback? Or just keep it within this thread given
> >> the way it's leaning? (or unless that consensus changes)
> >>
> >> Ultimately in my web/UI project the reduction (after using
> function(...))
> >> is something like...
> >>
> >> Failable.asFunction(Parent::getChild)
> >> .andThen(Optional::ofNullable)
> >> .andThen(o -> o.map(Child::getGrandChild))
> >> .andThen(o-> o.map(GrandChild::getName).orElse(defaultValue));
> >>
> >> vs my util method
> >>
> >> FunctionUtils.nested(Parent::getChild, Child::getGrandChild,
> >> GrandChild::getName, defaultValue);
> >>
> >> So it's still a big difference in clarity for me, given how often its
> used.
> >> FWIW - My project is using Vaadin, and this util function is used to
> bind
> >> nested bean properties to Vaadin input fields. On that note - In
> addition
> >> to the bean "getter" binding, it also uses a similar util method to bind
> >> bean "setter" methods - because input fields obviously need access to
> both.
> >> The setter util call looks similar, with the last argument being
> >> a BiConsumer...
> >>
> >> FunctionUtils.nested(Parent::getChild, Child::getGrandChild,
> >> GrandChild::setName);
> >>
> >> Although in general this code does not reference any Vaadin specific
> >> functionality, the overall use case may be quite specific to those
> needs,
> >> so all of these utilities may be better suited to a utils class within a
> >> vaadin specific library.
> >>
> >> Dan
> >>
> >> On Fri, Aug 4, 2023 at 9:11 PM Gary Gregory
> >> wrote:
> >>
> >>> The function() method is a great technique, it's now in Functions and
> >>> FailableFunction (git master).
> >>>
> >>> I'll see later if it can be used within Lang. I know I can use it in
> >> other
> >>> projects.
> >>>
> >>> Wrt an API for a vararg of functions that implements chaining
> internally,
> >>> I'm not so sure. I've though I needed something like that in past, but
> >> I've
> >>> always ended up with other coding patterns I found better at the time
> for
> >>> whatever reason..
> >>>
> >>> Gary
> >>>
> >>> Gary
> >>>
> >>> On Fri, Aug 4, 2023, 3:24 PM Gary Gregory
> >> wrote:
> >>>
> Worth adding adding function(Function)? Seems low cost to add it
> FailableFunction.
>
> Gary
>
> On Fri, Aug 4, 2023, 2:04 PM Rob Spoor wrote:
>
> > With just one simple utility method you can get all the cha
Re: [commons-lang] Comments on new FunctionUtils / nested lambda feature
I don't think that function chaining with varargs works, except with
UnaryOperator. After all, the output type of the first must be
compatible with the input type of the second, the output type of the
second must be compatible with the input type of the third, etc.
If you want to continue this way, the best option would be to have some
overloads:
Function nested(
Function first,
Function second)
Function nested(
Function first,
Function second,
R defaultValue)
Function nested(
Function first,
Function second,
Function third)
Function nested(
Function first,
Function second,
Function third,
R defaultValue)
...
If you're lazy you can delegate the overload with N functions to the
overload with N-1 functions:
Function nested(
Function first,
Function second,
Function third,
Function fourth,
R defaultValue) {
return nested(first, nested(second, third, fourth),
defaultValue);
}
Rob
On 06/08/2023 01:28, Gary Gregory wrote:
I'm not sure the "nested" example API is quite what it should be, because
the last argument is the default value, you cannot make the input functions
a vararg, which seems very limiting. I should be able to use the same API
whether I need to go 1, 2, or N functions deep. I'm saying the above
independently of whether this type of code should be in Lang.
Gary
On Sat, Aug 5, 2023, 9:27 AM Daniel Watson wrote:
Nice.
Sounds like everyone is leaning towards "no". Would it be worth submitting
a PR to include more usage examples - which I assume could also serve as a
place to collect more feedback? Or just keep it within this thread given
the way it's leaning? (or unless that consensus changes)
Ultimately in my web/UI project the reduction (after using function(...))
is something like...
Failable.asFunction(Parent::getChild)
.andThen(Optional::ofNullable)
.andThen(o -> o.map(Child::getGrandChild))
.andThen(o-> o.map(GrandChild::getName).orElse(defaultValue));
vs my util method
FunctionUtils.nested(Parent::getChild, Child::getGrandChild,
GrandChild::getName, defaultValue);
So it's still a big difference in clarity for me, given how often its used.
FWIW - My project is using Vaadin, and this util function is used to bind
nested bean properties to Vaadin input fields. On that note - In addition
to the bean "getter" binding, it also uses a similar util method to bind
bean "setter" methods - because input fields obviously need access to both.
The setter util call looks similar, with the last argument being
a BiConsumer...
FunctionUtils.nested(Parent::getChild, Child::getGrandChild,
GrandChild::setName);
Although in general this code does not reference any Vaadin specific
functionality, the overall use case may be quite specific to those needs,
so all of these utilities may be better suited to a utils class within a
vaadin specific library.
Dan
On Fri, Aug 4, 2023 at 9:11 PM Gary Gregory
wrote:
The function() method is a great technique, it's now in Functions and
FailableFunction (git master).
I'll see later if it can be used within Lang. I know I can use it in
other
projects.
Wrt an API for a vararg of functions that implements chaining internally,
I'm not so sure. I've though I needed something like that in past, but
I've
always ended up with other coding patterns I found better at the time for
whatever reason..
Gary
Gary
On Fri, Aug 4, 2023, 3:24 PM Gary Gregory
wrote:
Worth adding adding function(Function)? Seems low cost to add it
FailableFunction.
Gary
On Fri, Aug 4, 2023, 2:04 PM Rob Spoor wrote:
With just one simple utility method you can get all the chaining you
want:
public static Function function(Function
func) {
return func;
}
This doesn't look very useful, but it allows you to turn a method
reference or lambda into a typed Function without needing a cast.
After
that it's really simple using what's provided in the Java API:
Function func = function(MyBean::getChild)
.andThen(Child::getName);
You want a default value? Almost just as easy:
someFrameworkThing.setProperty(function(ParentBean::getChild)
.andThen(ChildBean::getName)
.andThen(Optional::ofNullable)
.andThen(o -> o.orElse("defaultName"));
On 04/08/2023 16:04, Daniel Watson wrote:
Asking for comments and thoughts on a potential new feature. Already
developed in a commons-like style, but dont want to submit PR
without
discussion as it may be considered out of scope or too use case
specific.
Justification and details...
I've run into a scenario a few times where nested lamba functions
would
be
incredibly useful. e.g.
MyBean::getChild::getName
Obviously this is not a language feature, but can be simulated in a
useful
