Re: Optional.isEmpty()

[Roger Riggs]

Hi,

IMHO,boolean isEmpty() would be a good complement to the existing 
empty() method.


$.02, Roger


On 4/24/2017 1:15 PM, Anthony Vanelverdinghe wrote:

Hi Peter

I'd say no: it's merely the negation of an existing method, and given 
that the bar for adding methods to Optional is set very high (see e.g. 
[1] and [2]), I don't see how this one would meet it.


Moreover, I don't see any issues with simply writing:

return !cf.findModule(target).isPresent();

and there are plenty of one-liners that don't use boolean negation as 
well, for example:


return cf.findModule(target).orElse(null) == null; // [3]
return cf.findModule(target).map(m -> false).orElse(true); // [4]
return cf.findModule(target).stream().count() == 0;
return cf.findModule(target).stream().allMatch(m -> false);
return cf.findModule(target).isPresent() ^ true;
...
return cf.findModule(target).equals(Optional.empty());

Adding a static import to the last one gets you very close to the 
proposed method already:

return cf.findModule(target).equals(empty());

Of course, another option is to introduce a variable to avoid the 
combination of boolean negation and method chaining:

boolean moduleFound = cf.findModule(target).isPresent();
return !moduleFound;

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8057557
[2] https://bugs.openjdk.java.net/browse/JDK-8058707
[3] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012273.html
[4] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012290.html



On 22/04/2017 11:40, peter.levart at gmail.com (Peter Levart) wrote:

Hi,

Seeing the following line in some JDK test that was up for review:

  return cf.findModule(target).orElse(null) == null;

I immediately jumped to suggest it would look better if written as:

  return !cf.findModule(target).isPresent();


But then I leaned back and asked myself: "Would it really?"

The boolean negation in front of a chain of method calls tends to
visually disappear from the view when we finally reach the offending
method and might get missed when quickly browsing the code. In this
respect, ".orElse(null) == null" is actually better. But the best would
of course be something like that:

  return cf.findModule(target).isEmpty();

What do you think? Would this pull its weight?

Regards, Peter

Re: Optional.isEmpty()

[Anthony Vanelverdinghe]

Hi Peter

I'd say no: it's merely the negation of an existing method, and given 
that the bar for adding methods to Optional is set very high (see e.g. 
[1] and [2]), I don't see how this one would meet it.


Moreover, I don't see any issues with simply writing:

return !cf.findModule(target).isPresent();

and there are plenty of one-liners that don't use boolean negation as 
well, for example:


return cf.findModule(target).orElse(null) == null; // [3]
return cf.findModule(target).map(m -> false).orElse(true); // [4]
return cf.findModule(target).stream().count() == 0;
return cf.findModule(target).stream().allMatch(m -> false);
return cf.findModule(target).isPresent() ^ true;
...
return cf.findModule(target).equals(Optional.empty());

Adding a static import to the last one gets you very close to the 
proposed method already:

return cf.findModule(target).equals(empty());

Of course, another option is to introduce a variable to avoid the 
combination of boolean negation and method chaining:

boolean moduleFound = cf.findModule(target).isPresent();
return !moduleFound;

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8057557
[2] https://bugs.openjdk.java.net/browse/JDK-8058707
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012273.html
[4] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012290.html


On 22/04/2017 11:40, peter.levart at gmail.com (Peter Levart) wrote:

Hi,

Seeing the following line in some JDK test that was up for review:

  return cf.findModule(target).orElse(null) == null;

I immediately jumped to suggest it would look better if written as:

  return !cf.findModule(target).isPresent();


But then I leaned back and asked myself: "Would it really?"

The boolean negation in front of a chain of method calls tends to
visually disappear from the view when we finally reach the offending
method and might get missed when quickly browsing the code. In this
respect, ".orElse(null) == null" is actually better. But the best would
of course be something like that:

  return cf.findModule(target).isEmpty();

What do you think? Would this pull its weight?

Regards, Peter

Re: Optional.isEmpty()

[Sander Mak]

> On 22 Apr 2017, at 11:40, Peter Levart  wrote:
>return cf.findModule(target).isEmpty();
> 
> What do you think? Would this pull its weight?

If I had a nickel for each time I started typing .isEm.., I'd have a 
respectable nickel collection. Big +1 from me.


Sander

Re: Optional.isEmpty()

[dalibor topic]

On 24.04.2017 10:26, Andrew Dinn wrote:

Ah, bike-shedding!

Personally, I much prefer isAbsent() to isNotPresent(), presence and
absence being a historically well-sanctioned English language pairing.

[n.b. I'll grant that my preference for C18th literature over Comp Sci
argot might have swayed my judgement in this matter so I'll leave it to
others to sanction or reject that suggestion via a conformantly aligned,
textually rendered act of pollification (i.e. go on, post yer +/-1
follow-ups)]


If we're going with fine aged literature references for naming things, 
then isBarren() might signify appealing, yet slightly terrifying 
existential emptiness. [0] [1]


cheers,
dalibor topic

[0] 'The Draculas were, says Arminius, a great and noble race, though 
now and again were scions who were held by their coevals to have had 
dealings with the Evil One. They learned his secrets in the Scholomance, 
amongst the mountains over Lake Hermanstadt, where the devil claims the 
tenth scholar as his due. In the records are such words as 
‘stregoica’—witch, ‘ordog,’ and ‘pokol’—Satan and hell; and in one 
manuscript this very Dracula is spoken of as ‘wampyr,’ which we all 
understand too well. There have been from the loins of this very one 
great men and good women, and their graves make sacred the earth where 
alone this foulness can dwell. For it is not the least of its terrors 
that this evil thing is rooted deep in all good; in soil barren of holy 
memories it cannot rest.”'


[1] "I desired that I might pass my life on that barren rock, wearily, 
it is true, but uninterrupted by any sudden shock of misery. If I 
returned, it was to be sacrificed or to see those whom I most loved die 
under the grasp of a daemon whom I had myself created."


--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: Optional.isEmpty()

[Andrew Dinn]

On 22/04/17 14:31, Jonathan Bluett-Duncan wrote:
> Your reasoning has personally convinced me that a method like `isEmpty()`
> would pull its weight. However, at the risk of bikeshedding, I think it
> should be named differently, as `isEmpty()` immediately makes me think that
> `findModule()` returns a List, which I'd easily find confusing.
> 
> How about `isNotPresent()` instead?

Ah, bike-shedding!

Personally, I much prefer isAbsent() to isNotPresent(), presence and
absence being a historically well-sanctioned English language pairing.

[n.b. I'll grant that my preference for C18th literature over Comp Sci
argot might have swayed my judgement in this matter so I'll leave it to
others to sanction or reject that suggestion via a conformantly aligned,
textually rendered act of pollification (i.e. go on, post yer +/-1
follow-ups)]

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Optional.isEmpty()

[Jonathan Bluett-Duncan]

Hi Peter,

Your reasoning has personally convinced me that a method like `isEmpty()`
would pull its weight. However, at the risk of bikeshedding, I think it
should be named differently, as `isEmpty()` immediately makes me think that
`findModule()` returns a List, which I'd easily find confusing.

How about `isNotPresent()` instead?

Best regards,
Jonathan

On 22 April 2017 at 10:40, Peter Levart  wrote:

> Hi,
>
> Seeing the following line in some JDK test that was up for review:
>
> return cf.findModule(target).orElse(null) == null;
>
> I immediately jumped to suggest it would look better if written as:
>
> return !cf.findModule(target).isPresent();
>
>
> But then I leaned back and asked myself: "Would it really?"
>
> The boolean negation in front of a chain of method calls tends to visually
> disappear from the view when we finally reach the offending method and
> might get missed when quickly browsing the code. In this respect,
> ".orElse(null) == null" is actually better. But the best would of course be
> something like that:
>
> return cf.findModule(target).isEmpty();
>
> What do you think? Would this pull its weight?
>
> Regards, Peter
>
>