Thanks again Ken ! One step at a time... Seems I'm now falling in the trap described here: https://groups.google.com/g/capnproto/c/9J_AOQzSEbU/m/qpuEjQXhBAAJ So I'm wondering now if there is an available example of C++ implementation of a RPC schema using inheritance, similar to the Calculator example.
Thanks Christophe Le vendredi 14 octobre 2022 à 22:48:28 UTC+2, [email protected] a écrit : > Hi Christophe, > > The problem is here: > > On Mon, Oct 10, 2022 at 5:41 AM Christophe Alexandre < > [email protected]> wrote: > >> auto objectInfo = promise.getObjectInfo(); >> > auto object = objectInfo.getObject(); >> > > Note that you are operating on a promise here. The RPC has not actually > completed yet. The `object` you have obtained here is a promised future > object. You can start calling methods on it before the original call has > actually completed. This is called "promise pipeline" -- or, jokingly, > "time travel", on the web site. https://capnproto.org/rpc.html > > >> bool isA = objectInfo.getIsA(); //not implemented >> > > This part doesn't work because pipelining on a boolean value is not > supported. Instead, you need to wait for the promise to complete, and then > you can access the boolean value on the result: > > auto promise2 = promise.then([](auto response) { > bool isA = response.getObjectInfo().getIsA(); > }); > > Or, if you have a WaitScope: > > auto response = promise.wait(waitScope); > bool isA = response.getObjectInfo().getIsA(); > > -Kenton > > >> >> Is it because of the Bool type ? >> >> Thanks ! >> Christophe >> >> Le samedi 8 octobre 2022 à 15:26:42 UTC+2, Christophe Alexandre a écrit : >> >>> Thanks a lot for your very clear answer. >>> >>> Christophe >>> >>> Le vendredi 7 octobre 2022 à 22:42:04 UTC+2, [email protected] a >>> écrit : >>> >>>> Hi Christophe, >>>> >>>> There is no built-in mechanism for this. Instead, you have to build >>>> this into your interface. >>>> >>>> Note that a `Client` object can be "safely" cast to any type using >>>> `client.castAs<SomeInterfaceType>()`. I say "safely" meaning: you won't >>>> violate C++ memory safety by this cast, even if the server doesn't >>>> actually >>>> implement the type. Instead, if you cast to the wrong type, method calls >>>> on >>>> that type will fail with UNIMPLEMENTED exceptions. The exception is >>>> produced on the server side; the client side does not actually know the >>>> destination type so cannot predict whether the method is supported. >>>> >>>> To that end, one way to query the type would be to simply try to call a >>>> method on `ConcreteA` or `ConcreteB` and see if it fails with >>>> `exception.getType() == kj::Exception::Type::UNIMPLEMENTED`. >>>> >>>> But if you'd like to avoid the round trip, then I would suggest that >>>> `getAbstracts()` should return a list that contains not just the interface >>>> pointers, but also associated metadata identifying what type it is. >>>> >>>> -Kenton >>>> >>>> On Fri, Oct 7, 2022 at 5:05 AM Christophe Alexandre < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> Sorry for the newbie question. >>>>> >>>>> I've read the following thread and this is related to the same kind of >>>>> question. >>>>> https://groups.google.com/g/capnproto/c/XLo5RPLpVBg/m/LI_sGi72AgAJ >>>>> >>>>> With following schema example: >>>>> interface Abstract {} >>>>> interface ConcreteA extends(Abstract) {} >>>>> interface ConcreteB extends(Abstract) {} >>>>> interface Object { >>>>> getAbstracts @0 () -> (abstracts :List(Abstract)); >>>>> } >>>>> >>>>> When implementing getAbstracts on the server side, only ConcreteA or >>>>> ConcreteB objects are constructed and returned. >>>>> My question is: on the client side, what is the best practice for >>>>> determining the Abstract object concrete type and casting it to ConcreteA >>>>> or ConcreteB. Something equivalent to C++ dynamic_cast. >>>>> >>>>> Thanks ! >>>>> Christophe Alexandre >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Cap'n Proto" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com >> >> <https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/3202c255-b169-47f3-a5f8-0005ddd3a9d9n%40googlegroups.com.
