I don't quite understand. You would never see a `bar` on the wire, just like you can't instantiate a interface/abstract-class in a OO language. You can only send concrete types on the wire. You just have the ability to downcast to a `bar` at run-time.
In java lingo I'm really just asking for "implment bar" to be added to the class defs of the message types, and to define "bar" as a interface someplace. I don't think it has much (any?) meaning outside of oo languages. On Friday, August 14, 2020 at 8:06:09 AM UTC-7 [email protected] wrote: > Hmm, would `Bar` be allowed to be used as a type in schemas? If so, when > you receive an arbitrary `Bar` on the wire, how would you figure out which > layout to use? > > If `Bar` is not allowed on the wire then I can imagine how to implement > this, but I think a lot of people would be surprised by such a restriction. > > -Kenton > > On Thu, Aug 13, 2020 at 9:55 PM Jon Ross <[email protected]> wrote: > >> > But the big problem with this is that you can't ever add a new field to >> Bar >> >> Yes you can, if it's just an interface and the fields need to exist >> individuals in each message. If you have a field in bar call "theThing", >> and it's id is 7 in one message, and 14 in another that's fine, as long as >> it exists. simple for the compiler to check that all fields in bar exist in >> any message that "extends/inherits" it. at runtime it's just a interface >> you can slap on any message that uses it. If you want to add a new field to >> bar, you have to add it to all the messages individuals, and their ids will >> be specific to that message.... at least that's how I'd do it.... >> >> On Monday, July 20, 2020 at 5:00:31 PM UTC-7 [email protected] wrote: >> >>> If you have a struct Foo whose fields are a strict superset of some >>> other struct Bar (with matching field numbers and everything), then you can >>> convert one to the other like: >>> >>> Foo::Reader foo = ...; >>> Bar::Reader bar = capnp::AnyStruct::Reader(foo).as<Bar>(); >>> >>> (Or vice versa.) >>> >>> But the big problem with this is that you can't ever add a new field to >>> Bar, because it would force you to renumber all the later fields of Foo, >>> which would be a backwards-incompatible change. >>> >>> In general I instead recommend that Foo should contain a field of type >>> Bar. This seems to suit most use cases just fine. >>> >>> BTW, note that RPC interfaces in Cap'n Proto do support inheritance. >>> It's only structs that don't. >>> >>> -Kenton >>> >>> On Sun, Jul 19, 2020 at 11:08 PM <[email protected]> wrote: >>> >>>> >>>> I understand real inheritance is a hornets nest or complex weirdness, >>>> and I don't need that. >>>> >>>> but could we add a really simple version? >>>> >>>> like all the msgs have a common 5 fields in them. make the common >>>> fields an interface that all my msgs inherit from? >>>> >>>> I don't expect to ever instantiate a concrete version of the "base" >>>> class. I just want to pass the derived msgs to a function that expects the >>>> base-type. >>>> >>>> -- >>>> 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/e08ca0bc-b386-4d04-b77d-569be721009do%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/capnproto/e08ca0bc-b386-4d04-b77d-569be721009do%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/43bf6eef-1856-405d-8b6e-db638f36c769n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/capnproto/43bf6eef-1856-405d-8b6e-db638f36c769n%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/d7759674-a7d5-46df-83be-07e69c2fa492n%40googlegroups.com.
