Firstly, I must say that I don't generally recommend inheriting from lists in this context. The code, as an implementation detail, tries to detect things that look like lists, and switches to treat it as "repeated" data. Sometimes, pretty rarely, something *looks* like a list, but should be treated as an object. The important difference is that when handling a list it serializes the *contents* of the list - it doesn't look at the properties etc of the list itself. You can switch between the two modes via the IgnoreListHandling flag on either ProtoContractAttribute or MetaType.
Marc On 28 June 2012 13:51, Joel Carrier <[email protected]> wrote: > Yes it does. Thanks. > > Where can I read more about this disabling of list-handling and its > effects? > > > On Thu, Jun 28, 2012 at 8:31 AM, Marc Gravell <[email protected]>wrote: > >> Well, until I get around to re-implementing it for v2, GetProto<T> will >> just make a quiet apology. But to answer your question, consider an example >> such as ItemList<Customer> >> >> Item<TItem> could be (I can't remember how v1 implements this) something >> like >> >> message Item_Customer { >> optional Customer Item = 1; >> } >> >> On the subject of ItemList<TItem> - unless you disable list-handling >> (separate topic), this will be treated *entirely* as just a List<TItem> - >> so no specific message is generated. As per my previous comment, such a >> list is then semantically identical to >> >> message SomeWrapper { >> repeated Item_Customer Items = 1; >> } >> >> Make sense? >> >> Marc >> >> On 28 June 2012 13:24, Joel Carrier <[email protected]> wrote: >> >>> Thanks a lot for the explanation Marc. >>> >>> I'm currently investigating some interop issues we're having and I'm >>> starting to realize that this might be the source of the problem. >>> >>> [CollectionDataContract(Name = "ItemList")] >>> public class ItemList<TItem> : List<Item<TItem>> where TItem : class >>> ... >>> where >>> >>> [DataContract(Name = "Item")] >>> public class Item<TItem> where TItem : class >>> { >>> [DataMember(Order = 1, Name = "Item")] >>> public TItem Item { get; set; } >>> ... >>> >>> The TItems are classes generated from .proto files. So we're mixing the >>> functionality (annotated classes vs. proto files). >>> >>> I think we're breaking a lot of "rules" here and I'm wondering how this >>> could ever generate valid .proto files. >>> That is, if it were to work, I have trouble picturing what Serializer. >>> GetProto<ItemList>() might output. >>> >>> This does appear to be working between clients using protobuf-net but I >>> guess what I'm looking for is confirmation that this would probably not >>> work nicely interop-ing with other Protocol Buffer libraries. >>> >>> (Note: I'm new to this stuff, so if I'm not making any sense at all let >>> me know and I'll return with a smarter question.) >>> >>> >>> Joel >>> >>> >>> On Wednesday, June 27, 2012 4:07:49 PM UTC-4, Marc Gravell wrote: >>>> >>>> The data is of course compatible. A `List<Foo>` is directly mappable to >>>> .proto via for example: >>>> >>>> message SomeOuterMessage { >>>> repeated Foo items = 1; >>>> } >>>> >>>> In fact, for that reason, serializing a List<Foo> will produce >>>> **exactly** the same data on the wire as serializing: >>>> >>>> [ProtoContract] >>>> public class Whatever { >>>> [ProtoMember(1)] >>>> public List<Foo> Items {get;set;} >>>> } >>>> >>>> which is (give or take) what you will get if you feed the above .proto >>>> into "protogen" (protobuf-net's entirely optional code generator for >>>> handling .proto definitions) >>>> >>>> Marc >>>> >>>> >>>> >>>> On 27 June 2012 16:21, Joel Carrier <[email protected]> wrote: >>>> >>>>> Hi Marc, >>>>> >>>>> Could you elaborate on your note: (note: this is specific to >>>>> protobuf-net, not "protocol buffers" more widely) >>>>> >>>>> What are the implications if communicating with non-protobuf-net >>>>> targets? (ie. java, python, ... applications) >>>>> >>>>> Joel >>>>> >>>>> >>>>> On Wednesday, June 20, 2012 9:05:49 AM UTC-4, Marc Gravell wrote: >>>>>> >>>>>> (note: this is specific to protobuf-net, not "protocol buffers" more >>>>>> widely), but yes: that (a generic list) would work fine, as long as the >>>>>> property has been marked for serialization and given a number. There also >>>>>> doesn't need to be a "set" accessor, although it can make full use of a >>>>>> "set" - i.e. if it finds the list is "null", it will create a new list of >>>>>> the appropriate type and use the "set" to update the object. >>>>>> >>>>>> So, your code would be fine if it has been designated a number, or a >>>>>> related example: >>>>>> >>>>>> [ProtoMember(4)] >>>>>> public List<Order> Orders { get { return orders; } } >>>>>> private readonly List<Order> orders = new List<Order>(); >>>>>> >>>>>> Marc >>>>>> (protobuf-net) >>>>>> >>>>>> On 20 June 2012 13:08, Farooq Mushtaq <[email protected]>wrote: >>>>>> >>>>>>> How can we serialize list of objects by using protobuf-net? Is >>>>>>> protobuf-net support list of objects like >>>>>>> public List(ABC) DEF >>>>>>> { >>>>>>> get; >>>>>>> set; >>>>>>> } >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Protocol Buffers" group. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/**ms**g/protobuf/-/W0yySDcbES8J<https://groups.google.com/d/msg/protobuf/-/W0yySDcbES8J> >>>>>>> . >>>>>>> To post to this group, send email to [email protected]. >>>>>>> To unsubscribe from this group, send email to protobuf+unsubscribe@* >>>>>>> *googlegro**ups.com <protobuf%[email protected]>. >>>>>>> For more options, visit this group at http://groups.google.com/** >>>>>>> group**/protobuf?hl=en<http://groups.google.com/group/protobuf?hl=en> >>>>>>> . >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Marc >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Protocol Buffers" group. >>>>> To view this discussion on the web visit https://groups.google.com/d/* >>>>> *msg/protobuf/-/2pcXp7q9LCcJ<https://groups.google.com/d/msg/protobuf/-/2pcXp7q9LCcJ> >>>>> . >>>>> >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to protobuf+unsubscribe@** >>>>> googlegroups.com <protobuf%[email protected]>. >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/protobuf?hl=en <http://groups.google.com/group/protobuf?hl=en>. >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Marc >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Protocol Buffers" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/protobuf/-/SUzHf4_n0O4J. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/protobuf?hl=en. >>> >> >> >> >> -- >> Regards, >> >> Marc >> > > -- Regards, Marc -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
