PropertyMapper.from(value).

[nosan]

add a new method PropertyMapper.from(value).

[philwebb]

Thanks for the PR. I actually considered adding this method at the time but I was nervous about providing an overloaded version of a lambda method. I've seen a few people suggest that it's not good practice to do so.

Perhaps we use a different method name instead? Maybe fromValue(...)?

[nosan]

@philwebb Yes, you are right, but this could happen only for explicit null value.

Thoughts?

Thanks.

[philwebb]

I'm at the limit of the knowledge on the subject and I can't remember who told me about it. I certainly like the feel of of not needing a different method name. I'll flag for team attention and see if there's a general consensus.

[philwebb]

@rstoyanchev @smaldini Was it either of you two that mentioned about not overloading lambda calls? Perhaps during some of the early reactor work?

[simonbasle]

@philwebb I can remember that we actively avoided something slightly different in Reactor (that was a focus of the 3.1 release): avoid to provide several signatures that all take a functional interface with same number of parameters, eg. from(Supplier) vs from(Callable), because these would become ambiguous when using lambdas.

It is also better for integration into languages like Kotlin (cc @sdeleuze) to avoid functional interface overloads at all (as Kotlin has optional parameters, which brings back the ambiguity even with Consumer<T> vs BiConsumer<T, R>).

I don't think from(T) vs from(Supplier<T>) falls into this category, and thus should be fine 😉