Suggestion for new tuple methods: flattening of optionals

[jh3141]

I've been finding the following set of methods for order 2 tuples quite handy, and I'd imagine they'd be pretty easy to extend via your code generator...

    public static <T1, T2> Optional<Tuple2<T1,T2>> flatten1 (Tuple2<Optional<T1>, T2> tuple)
    {
        return tuple.v1.map (just1 -> Tuple.tuple(just1, tuple.v2));
    }
    public static <T1, T2> Optional<Tuple2<T1,T2>> flatten2 (Tuple2<T1, Optional<T2>> tuple)
    {
        return tuple.v2.map (just2 -> Tuple.tuple(tuple.v1, just2));
    }
    public static <T1, T2> Optional<Tuple2<T1,T2>> flatten12 (Tuple2<Optional<T1>, Optional<T2>> tuple)
    {
        return tuple.v1.flatMap ((T1 just1) ->
                tuple.v2.map ((T2 just2) -> Tuple.tuple(just1, just2)));
    }

[lukaseder]

Thanks for your suggestion. What's the use-case for these operations?

[jh3141]

I commonly use them when fetching a group of related items from a database to perform an operation on, but the operation cannot progress if any of the items is missing.

For example, from my current project:

        stationBlacklist.save (
            Seq.seq (indexData.getItems()).crossApply (ItemIndexingData::getBlackListStations)
                .map (rpiAndStationId  -> Tuples.flatten2 (rpiAndStationId.map2 (stations::get)))   // get the actual station from its ID, if possible
                .transform (StreamUtils::flattenOptionalSeq)                                // lose the empty tuples relating to any missing stations
                .map (StationItemBlacklist::fromTuple) 
                .toList ());

[lukaseder]

Am I understanding this correctly, your getBlackListStations() method returns something allong the lines of a Stream<Optional<STATIONID>>? That doesn't seem like a reasonable type to me. Why not just omit the stations that are not present and return Stream<STATIONID> instead?

I'm not yet convinced that the "flattening" concept is a sufficiently reusable one to be added to the API. Besides, the number of methods to be added to the Tuples class will either explode, or we'll limit this to some degree, e.g. like 2, but in that case, why bother?

[jh3141]

In the snippet provided, stations::get return Optional<Station>, so the result of:

rpiAndStationId.map2 (stations::get)

is a Tuple2<RPItem, Optional<Station>> -- as the next processing step requires a station, I need to then remove the items from the stream that don't contain a station; I do this in two steps by first moving the Optional<> to outside of the tuple, and then removing them from the stream before finally processing them.

[lukaseder]

stations::get return Optional<Station> ... rpiAndStationId.map2 (stations::get) is a Tuple2<RPItem, Optional<Station>>

I'm sorry would you mind posting all of your involved types in this issue, or in a gist? I'm finding it a bit hard to reason about your types right now. Alternatively, a more reduced, minimal example that does not involve any of your business logic might help, too.

[lukaseder]

Closing this as "won't fix". There isn't a clear enough use-case to justify the addition.