Re: [capnproto] Best practice for dynamic_cast equivalent method for extended interfaces

2022-10-07 Thread 'Kenton Varda' via Cap'n Proto
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

2022-10-07 Thread Christophe Alexandre
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.