Closed diogob closed 9 months ago
@gustavoguichard I think I got collect
working. Actually the restriction I found only impedes us from typing collectSequence
since there we need to preserve the order of the keys.
~@gustavoguichard just realized there is still some work to do generalizing some types such as the Unpack
ones. I have converted back to draft and will mark as ready for review as soon as I finish those bits.~
Nevermind generalizing the Unpack
types. I just tried and I remembered why I haven't done it so far. It's not trivial and also not necessary for a release. Once we start gearing up to the major release we can revisit them.
Nevermind generalizing the
Unpack
types.
You mean being able to use Unpack
with both df
and composable
?
Nevermind generalizing the
Unpack
types.You mean being able to use
Unpack
with bothdf
andcomposable
?
That's what I meant, since these two types have the same name but they behave in quite different ways. The DF UnpackResult
applies the ReturnType
, and the composable UnpackResult
just takes the result out of the promise.
But I wouldn't worry about this for this PR.
I have a proposal for new naming conventions, will send in another PR to avoid muddying the waters here
This should allow only valid types when using the composition primitives (a.k.a.
Composable
operations). Since the primitives do not have parsers on their input the type-safety not only makes sense but becomes essential to writing robust compositions.It is important to note that we rely on a type conversion from a union to a tuple. This type helper (generously shared here) uses the internal union order which means that the order when converting from a
Record
to a tuple is not stable. This is irrelevant to type ourcollect
function since it is applied in parallel. But I'm leaving this long note here to explain why implementing acollectSequence
with a Record input would be very challenging.