Right, so, what you're asking for isn't necessarily the same thing as what
other people asking for "inheritance" (even "interface inheritance")
typically want.
A lot of people who ask for inheritance specifically want to be able to do
this:
struct interface Bar { ... }
struct Foo implements Bar { ... }
struct Baz implements Bar { ... }
struct Message {
value @0 :Bar;
# May contain a Foo or a Baz.
}
I think if we added a way to declare "struct interfaces" in capnp schema
language, people would be confused to find that they can't actually use the
interface type in their schemas.
It sounds like you're fine with that -- all you want is to be able to write
code in whatever programming language which is polymorphic over struct
types that have the right common subset of fields.
I think the right way to solve your problem really depends on the language:
- In dynamic languages, you just use duck typing.
- In C++, you can use templates (which provide compile-time duck typing).
- In languages with implicit interfaces (e.g. Go and Haskell) you can
declare the interface in code and the capnp types will implicitly
implement it.
- In Java, perhaps you need an annotation which you can use to tell the
code generator to please declare the reader/builder as implementing some
interface:
struct Foo $Java.readerExtends("com.example.Bar") { ... }
This would cause the code generator to add the appropriate "extends"
declaration to your reader type; it's up to you to define the Bar interface
separately.
-Kenton
On Fri, Aug 14, 2020 at 1:21 PM Jon Ross <[email protected]> wrote:
>
> 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
> <https://groups.google.com/d/msgid/capnproto/d7759674-a7d5-46df-83be-07e69c2fa492n%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/CAJouXQn06PiqQitfHQWC%3DVqpVsRLpjxeedyvKnsnUvA7idOQJw%40mail.gmail.com.
