On Tue, Dec 2, 2008 at 10:04 PM, Petar Petrov <[EMAIL PROTECTED]>wrote:
> How useful is a remove method on a repeated composite field? None has asked > about such. Do you have any use cases which require it? What are they? > > If you want to remove a value from a repeated composite field, you > basically have to create the same composite value and pass it to .remove(). > When can this be useful? > > I think removal of composite values doesn't make much sense. Maybe even > slicing ( __getslice__ could be usefull, but __setslice__ very unlikely). > Just as useful as the remove() method for lists of objects in Python. I think repeated scalar and composite fields should act exactly like lists, because that's intuitively what they are. There's no technical downside to including the remove() method, and it brings repeated composites more in line with repeated scalars. Also, you don't have to recreate the composite in order to pass it to .remove() - you could easily have another reference to the object stored somewhere. And I don't know why nobody would want to assign to lists of objects - this kind of thing is very common. In fact, this whole patch was pretty easy. There must be some reason it >> hasn't been done before. > > > The problem is not in adding slicing support. The problem is that if there > is a Python/C API at some point, it will be very hard to translate the > slicing support to the C++ API. However repeated scalar slicing is > translatable (using RepeatedField's Set/RemoveLast/Add methods) but I don't > think slicing of repeated composite fields is possible with the C++ API. > > I think we should only keep the repeated scalar slicing and maybe only > __getslice__ and __delslice__ for repeated composites. > Why should it matter if there's no slicing in the C++ API? Each implementation of Protocol Buffers should feel natural for each language; it shouldn't be held back just because some other language doesn't support the same features. The builder pattern is completely normal in Java, but the C++ version uses an entirely different strategy. Slicing is completely normal in Python. The repeated scalar and composite interfaces should be exactly the same. Everything is Python is polymorphic - it feels wrong if you can't do something with a list simply based on the types it contains. This is why I included a comment in the add() method saying it should be deprecated - the functionaly is superseded by append(), and there's no corresponding method in the repeated scalar class. Cheers, Alek Storm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
