A year or two ago I might have +1'd this. Having used my own lookup-like
API for something unrelated, that returns Optional, I can relate the
following:
- About half the time, if the Optional is actually not present, something
has gone horribly, horribly wrong; so you either write code that assumes
it's always present, or you get annoyed that you stupidly used it when you
have to unwrap it. Typical case: Two pieces of code both have a reference
to the Lookup (equivalent), they don't know about each other, but they do
have an order of precedence they run in, and if the first isn't run, the
second one won't be either. Yeah, they could share a reference to the
object they want to look up, but then they'd be carrying around a reference
to the Lookup and the object (greater leak potential), or they may
parameterize on different types and can't practically share a reference to
the same type - plenty of reasons you can wind up in that situation.
- The thing that's actually worthwhile about it is the methods that take a
lambda, but they ones on Optional have some serious shortcomings - you call:
public void ifPresent(Consumer<? super T> consumer) {
and there is nothing to tell you if your consumer was called or not (you
could call orElse() on optional - with some Lookups, that's going to
trigger a bunch of work a second time, when the code you're calling could
simply return a boolean.
- In the non-lambda usage, there's nothing but aesthetics to differentiate if
(foo == null) from if (foo.isPresent()) - which is to say: Java has nulls.
It's not going to stop having nulls, and everyone needs to get over it.
Yeah, James Gosling called it the billion dollar mistake or something like
that, but whether it is or isn't, pretty drapes in the foyer isn't going to
un-make it.
I could imagine +1'ing something like
<T> boolean ifPresent(Class<T> type, Consumer<T> consumer)
though
<T,R> R ifPresent(Class<T> type, Function<T,R> processor)
would probably, in the common case, be more useful, since the function
author can return a result that indicates if it ran easily enough. But you
can also create this for yourself anywhere:
public static <T, R> ifNonNull(Supplier<T>, Function<T,R> processor)
public static <T,R> specializedForLookup(Lookup lkp, Class<T> type,
Function<T,R> func) {
T obj = lkp.lookup(type);
return obj == null ? null : func.apply(obj);
}
and, well, you have to pass the Lookup, but is the value of not having to
pass one argument worth a potentially breaking change in a core class?
-Tim
On Thu, Jul 2, 2020 at 12:32 PM Hector Espert <[email protected]>
wrote:
> A few months ago, I created a draft PR to add a method in the Lookup class
> that returns a Java optional.
>
> https://github.com/apache/netbeans/pull/2063
>
> There wasn't any special reason. Only I used it to study how the Netbeans
> documentation works.
>
> If anybody is interested in that, I will continue with the development. If
> not, I will close the PR.
>
> Regards, Hector
>
--
http://timboudreau.com
