No worries. I'm not an official member of the Cap'n Proto project; I just
work on the Go bindings. You are correct that oneof is similar to unions
in Cap'n Proto.
Yeah, if you need an out-of-band signaling that a particular field is set
or not, then you can either use a union or wrap the field in a struct.
This is actually quite similar to the proto3 advice. Using unions:
struct MyStruct {
favoriteNumber :union {
noPreference @0 :Void;
// Indicates a lack of a favorite number. Selected by default since it
is the first ordinal in the union.
number @1 :Int64;
// The favorite number.
}
}
You can check for presence in C++ by using (and paraphrasing, since I use
the Go API much more often) `myStruct.getFavoriteNumber().which() ==
NUMBER`.
Otherwise, you can wrap the favorite number in a sub-struct:
struct MyStruct {
favoriteNumber @0 :FavoriteNumber;
}
struct FavoriteNumber {
number @0 :Int64;
}
You can check for presence using `myStruct.hasFavoriteNumber()`. I end up
using this approach because, more often than not, if presence of a scalar
is significant, it usually signifies a higher-order concept that should be
abstracted into a struct.
I have examples of both of these in catalog.capnp
<https://github.com/zombiezen/mcm/blob/master/catalog.capnp>, a schema I'm
using for one of my personal projects. See the File.Mode struct in
particular.
-Ross
On Thu, Mar 9, 2017 at 11:44 AM Sam Duke <[email protected]> wrote:
> I think the idea of an unset sentinel value is a little awkward as it
> conflates data validation with field presence which are nice concepts to
> keep separate (in part for consistency in how you perform data validation).
>
> As I understand it a union is synonymous to a Protobuf oneof field?
>
> Is the recommendation to use a union with only one member or use wrappers
> (like this
> https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto)
> which don't really fix the problem buy minimise it?
>
> Using unions everywhere would make the definitions of messages hard to
> read. It suppose some syntactic sugar around this might be useful :/
>
> Thanks for your prompt replies and help BTW. And sorry for my poor reading
> of your docs :)
>
> On Thu, 9 Mar 2017 at 19:15 Ross Light <[email protected]> wrote:
>
> Quite the opposite: it's so that scalar values always have a fixed offset
> from the beginning of the struct's data section. This may waste space on
> the wire, but makes scalar access consistent and avoids branches in the
> common case (read as fast).
>
> However, it's worth noting that reading a scalar field with a newer
> version of the schema will read the default value, so as the FAQ states,
> you can use this property to have an "unset" sentinel value or you can add
> a named union.
>
> On Thu, Mar 9, 2017 at 10:27 AM Sam Duke <[email protected]> wrote:
>
> Really confused why this was removed? Is it for less space on the wire?
> Field presence seems an excellent way to guard against regression as protos
> evolve.
>
> On Thu, 9 Mar 2017, 18:20 Ross Light, <[email protected]> wrote:
>
> Correct. In this respect, Cap'n Proto is very close to proto3 semantics.
>
> On Thu, Mar 9, 2017 at 10:08 AM Sam Duke <[email protected]> wrote:
>
> Looks like there's no hasX methods for scalars?
>
> On Thu, 9 Mar 2017, 15:57 Ross Light, <[email protected]> wrote:
>
> https://capnproto.org/faq.html#how-do-i-make-a-field-optional
>
> On Thu, Mar 9, 2017, 4:01 AM <[email protected]> wrote:
>
> I couldn't find an explicit mention of this on the website, curious if
> CapNProto has also removed field presence detection - it's a really useful
> feature to have!
>
> --
> 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].
> Visit this group at https://groups.google.com/group/capnproto.
>
> --
> 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].
> Visit this group at https://groups.google.com/group/capnproto.
>
> --
> 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].
> Visit this group at https://groups.google.com/group/capnproto.
>
--
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].
Visit this group at https://groups.google.com/group/capnproto.
