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/CAJouXQkAwKR-s_9WpyMm-ziAZe0miPBokz%2Bfmx_as%3DmXwROGdQ%40mail.gmail.com.
