I'm -1 on this - maybe I've voted differently before, but the more I see the optional tries in the POI API, the more I dislike them.
I thought about going through the lists ([1]/[2]) and give my two pence here, but basically there are very rare cases where I think, oh cool it's an Optional return - maybe when processing streams. Regarding to the question below: although we need that cumbersome way of introducing new methods for to-be-replaced APIs (especially for return values), I think the minimal (in my point of view) benefit of Optionals don't justify that - this is different for Enums, to eventually get rid of all the int constants. Andi [1] https://softwareengineering.stackexchange.com/questions/309134/why-is-using-an-optional-preferential-to-null-checking-the-variable [2] https://dzone.com/articles/using-optional-correctly-is-not-optional On 28.05.21 15:09, fannin...@apache.org wrote:
An example is spreadsheet Workbook#getSheet(String name) -- which returns null if no sheet is found. We could add a method Workbook#getOptionalSheet(String name) -- which returns an instance of java.util.Optional<Sheet>. Is this work worthwhile? I can probably add a few methods like this but probably don't have time to add lots of new methods. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
