I suppose the behaviour could be emulated by defining a message type for
each field type, and then using message-type fields only.  But having
the capability on the fields themselves would be nice, if it doesn't
exist already.

On Tue, 2008-12-02 at 14:45 -0700, Shane Green wrote:
> If I understand correctly, serializing a protocol-buffer message creates
> a byte-string that describes the fields of the serialized message.  The
> field descriptions include their type identifiers, field numbers, and
> current values.
> 
> An instance of the type of message that was serialized can then
> configure itself to be equal to the serialized message by parsing the
> byte-string representation.  By telling a message instance to parse its
> serialized representation, one is basically setting the instance's
> "value."
> 
> It would seem reasonable that this pattern be maintained down to the
> level of individual fields.  Meaning that message field instances could
> serialize themselves to byte-strings and initialize themselves from
> bytes-strings.
> 
> I can see multiple values to such a capability.  It would be possible,
> for example, to partially initialize message instances by initializing
> specific fields within the instance, which may be very useful for doing
> things like streaming messages.  Also, protocol-buffer fields could be
> used outside the context of protocol-buffer messages, which may or may
> not be valuable.  Does this capability already exist?
> 
> 
> 
> Thanks, 
> Shane
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, 2008-12-02 at 12:21 -0800, Kenton Varda wrote:
> > Cool!  Can you send this to me and Petar (cc'd) via
> > codereview.appspot.com?
> > 
> > 
> > On Tue, Dec 2, 2008 at 1:22 AM, Alek Storm <[EMAIL PROTECTED]>
> > wrote:
> >         There was already a remove() method for repeated scalars, but
> >         not for composites.  I added one without any difficulty.  Did
> >         I miss something?  In fact, this whole patch was pretty easy.
> >         There must be some reason it hasn't been done before.
> > 
> > 
> > It could easily be that no one had gotten around to it.  To be
> > perfectly honest, the Python code doesn't get very much attention
> > here.  :/
> >  
> >         The docs aren't on the wiki, so I can't add anything about
> >         this.  Are there plans to move it to the wiki, by any chance?
> > 
> > 
> > Unfortunately that would require a ton of work (to convert to wiki
> > markup) and the resulting docs would not be as nice.  If you'd like to
> > send me a change to the HTML, though, I could put it up.
> > 
> > > > 
> 


--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to