Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
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, ken...@cloudflare.com a
écrit :
> Hi Christophe,
>
> The problem is here:
>
> On Mon, Oct 10, 2022 at 5:41 AM Christophe Alexandre <
> christophe...@zellij.io> 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, ken...@cloudflare.com 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()`. 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 <
christophe...@zellij.io> 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 capnproto+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
>
>
> .
>
--
>> 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 capnproto+...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com
>>
>>
Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
Thanks again Kenton !
One step at a time. I'm now falling in the trap described
here: https://groups.google.com/g/capnproto/c/XLo5RPLpVBg/m/LI_sGi72AgAJ
I was wondering if there is a full C++ implementation example of a schema
containing inheritance such as the Calculator example.
Thanks !
Christophe
Le vendredi 14 octobre 2022 à 22:48:28 UTC+2, ken...@cloudflare.com a
écrit :
> Hi Christophe,
>
> The problem is here:
>
> On Mon, Oct 10, 2022 at 5:41 AM Christophe Alexandre <
> christophe...@zellij.io> 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, ken...@cloudflare.com 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()`. 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 <
christophe...@zellij.io> 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 capnproto+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
>
>
> .
>
--
>> 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 capnproto+...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com
>>
>>
Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
Hi Christophe,
The problem is here:
On Mon, Oct 10, 2022 at 5:41 AM Christophe Alexandre <
christophe.alexan...@zellij.io> 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, ken...@cloudflare.com 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()`. 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 <
>>> christophe...@zellij.io> 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 capnproto+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
.
>>> --
> 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 capnproto+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com
>
> .
>
--
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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/CAJouXQ%3DV-4mDXr9P5f-WHZHsQ-F7u19QSJTSdTsZW_CYuzu0xA%40mail.gmail.com.
Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
Hi,
Related to this, I tried the following schema:
interface MyType {
getName @0 () -> (name :Text);
}
struct ObjectInfo {
object @0 :MyType;
isA@1 :Bool;
}
interface Test {
getObjectInfo @0 () -> (objectInfo: ObjectInfo);
}
After generating the C++ classes, on the client side, there is a
getObject() method implemented on the ObjectInfo class but no getIsA().
auto request = testClient.getObjectInfoRequest();
auto promise = request.send();
auto objectInfo = promise.getObjectInfo();
auto object = objectInfo.getObject();
bool isA = objectInfo.getIsA(); //not implemented
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, ken...@cloudflare.com 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()`. 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 <
>> christophe...@zellij.io> 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 capnproto+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
>>>
>>>
>>> .
>>>
>>
--
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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/76ba9ec6-578f-443f-8ef3-75e66ab3e86an%40googlegroups.com.
Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
Thanks a lot for your very clear answer.
Christophe
Le vendredi 7 octobre 2022 à 22:42:04 UTC+2, ken...@cloudflare.com 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()`. 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 <
> christophe...@zellij.io> 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 capnproto+...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
>>
>>
>> .
>>
>
--
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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/f2c6f5d1-b3c5-4436-85c9-45cf24a0a0ddn%40googlegroups.com.
Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
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()`. 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 <
christophe.alexan...@zellij.io> 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 capnproto+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com
>
> .
>
--
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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/CAJouXQm%2B7xc5WzGMs1QaBsZBpCENf-Rr74oYW_VoxtEod0%2BnQg%40mail.gmail.com.
[capnproto] Best practice for dynamic_cast equivalent method for extended interfaces
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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/1613eaaf-6025-4eb0-90c3-a7f4a98a2e21n%40googlegroups.com.
