Why do your protocol message types have to map 1:1 with your legacy classes?
Generally, attempting to map inheritance onto Protocol Buffers doesn't work
very well.
You are right that you can use extensions, but unless you have a large
number of subclasses of OParameter, this isn't helpful. If the only
subclasses of OParameter are OStringParameter, OLongParameter, and
OListParameter, then I highly recommend defining OParameter as:
message OParameter {
// Only one of the following will be filled in.
optional int64 long_value = 1;
optional string string_value = 2;
repeated OParameter list_value = 3;
}
If you really wanted to use extensions instead, you could do:
message OParameter {
// Only one extension will be filled in.
extensions 1 to max;
}
extend OParameter {
optional int64 oparameter_long_value = 1;
optional string oparameter_string_value = 2;
repeated OParameter oparameter_list_value = 3;
}
This is logically equivalent to the first definition. The only difference
is logistical: you can define each extension field in a different .proto
file, and your program only needs to compile in the definitions of
extensions that it actually uses. So you can do:
// oparameter.proto
message OParameter {
// Only one extension will be filled in.
extensions 1 to max;
}
// olongparameter.proto
import "oparameter.proto";
extend OParameter {
optional int64 oparameter_long_value = 1;
}
// ostringparameter.proto
import "oparameter.proto";
extend OParameter {
optional string oparameter_string_value = 2;
}
// olistparameter.proto
import "oparameter.proto";
extend OParameter {
repeated OParameter oparameter_list_value = 3;
}
But again, if you only have these three subclasses, then this is overkill.
If you actually have a lot more (say, at least 10), then it might be
worthwhile.
Again, keep in mind that extensions are not inheritance -- they are a very
different concept which happens to be able to solve similar problems.
On Wed, Aug 5, 2009 at 1:31 AM, Tai wrote:
>
> Hi Kenton,
>
> Sorry the parameter classes are legacy code and persisted to the DB as
> well. So I have to figure out what's the best approach defining my
> proto classes.
>
> What I see is that there is the way of using extensions in the proto
> files. As far as I understand it is an extension of members (an not
> classes) in another proto file. Correct?
>
> So in my case the files in OStringParameterMessage.proto and
> OLongParameterMessage.proto extends OParameterMessage.proto with a
> member "value" of type string and int64.
>
> The OListParameterMessage.proto then extends it with a member value of
> type List (containing OParameterMessage.OParameter instances).
>
> In the OListParameter.writeObject() I build OParameter messages. But
> wouldn't there be a problem since the value is either of type String
> or Quantity (depending on the subclass of OParameter)? Probably I have
> to define different member names.
>
> Tai
>
>
> On 5 Aug., 03:05, Kenton Varda wrote:
> > Can you just have the OParameter message contain optional fields of type
> > string and int64, where only one of the two is ever set? Then don't have
> > specific types corresponding to OStringParameter and OLongParameter.
> >
> > On Tue, Aug 4, 2009 at 5:07 PM, Tai wrote:
> >
> > > Hi,
> >
> > > I have an (abstract) class:
> > > - OParameter with a member String key
> >
> > > Now there are also two subclasses of OParameter:
> > > - OStringParameter with a member String value
> > > - OLongParameter with a member long value
> >
> > > By using Protocol Buffers I define the proto files:
> > > - OParameterMessage.proto
> > > - OStringParameterMessage.proto
> > > - OLongParameterMessage.proto
> >
> > > The files are independent from each other (no extension is used). As
> > > far as I understand this is how Protocol Buffers should be used. All
> > > classes (OParameter, OStringParameter and OLongParameter) then
> > > implements the writeObject() and readObject() and each class just uses
> > > their Protocol message and sets their members. Like:
> > > - Class OStringParameter.writeObject() builds a message and sets only
> > > its member (value)
> > > - The superclass OParameter.writeObject() builds a message and sets
> > > only its member (key)
> >
> > > The same goes for the readObject().
> >
> > > Okay. So far so good. But now I have a class called OListParameter and
> > > its member (value) is a list of OParameter containing instances of
> > > both types: OStringParameter and OLongParameter.
> >
> > > How do I describe this in a proto file?
> >
> > > Thanks Tai
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
For more options, v