> On 26 Sep 2015, at 10:32, Tagir F. Valeev <amae...@gmail.com> wrote: > > Hello! > >>> Quite interesting and long awaited features (at least according to >>> StackOverflow questions). > > PS> All of them? or just the first? > > The first one is definitely the most requested feature. However, > additional methods for primitive optionals were requested at least > twice: > http://stackoverflow.com/q/29104968/4856258 > http://stackoverflow.com/q/23414903/4856258 >
> Something like mapOrElseGet was implicitly requested here > (though it's more look like ifPresentOrElse) > http://stackoverflow.com/q/23773024/4856258 > Thanks. >>> Isn't it a good idea to provide also a way >>> to transfer between Optional types like "mapToInt", "mapToObj", etc., >>> like it's done in Stream API? >>> > > PS> I don’t wanna go there, my response is transform Optional* into a > PS> *Stream. An argument for adding mapOrElseGet (notice that the > PS> primitive variants return U) is that other functionality can be composed > from it. > > Probably then it's better instead of adding map, filter, etc. just add > single "boxed()" method to convert OptionalDouble to Optional<Double>, > etc.? So if somebody really wants to chain optional calls, let them do > the boxing and use the features of normal Optional. > Some degree of parity will i think avoid confusion, but I was also pondering a boxed method, independent of the map/filter etc, if the more general usage (map.orElseGet, mapOrElseGet/fold) proves too difficult. I think it’s fine to to pollute OptionalInt etc with Optional but i want to avoid it for the other direction. Paul.
