[prev in list] [next in list] [prev in thread] [next in thread] 

List:       poi-dev
Subject:    Re: extending APIs to offer alternatives where existing APIs can return null
From:       Andreas Beeker <kiwiwings () apache ! org>
Date:       2021-05-28 17:23:18
Message-ID: f651e073-7661-acbd-6e09-52d2dd2834d1 () apache ! org
[Download RAW message or body]

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, fanningpj@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-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]