Gijs van Veen
Gijs van Veen
Im trying a builder approach instead, as suggested here https://github.com/GitLiveApp/firebase-kotlin-sdk/pull/448#discussion_r1450851712 The advantage of this compared to named arguments is that it is much easier to maintain.
@nbransby in case you werent aware, the builder approach is in the latest commit. Ive also tracked master again
> Should all functions that take a builder lambda be marked as inline to avoid the lambda allocation? I dont think that actually avoids anything. We can make the lambda...
@nbransby Ive removed the Async classes and made some changes so all builders funs are now inline. Ive annotated methods with `@PublishedAPI` if only used by the inline methods. The...
Ive included changes proposed by #456
> Looking good, whats the purpose of the Base... and Native... classes such as NativeQuery and s BaseTransaction? @Daeda88 So with expect/actuals classes you cannot implement code on the common...
> > Even though with a lot of the code, you kind of want it (e.g., most methods need to encode/decode their values). Base solves this by introducing an abstract...
No, im saying its not correct to do it like that in my opinion, for maintainability reasons. Because if you use that approach, every time something changes to sharedFunction you...
At the very least, we should have common ``` expect class Something { expect fun publicApi(parameter: String): Result } internal inline fun Something.sharedFunction(parameter: String, parsedMethod: (Any) -> Result): Result ```...