Kenton, You certainly can do that as well. However, as you pointed out, that's a lot of extra code that one would have to hand-write and maintain. This is why I thought it might be a good idea to solicit more opinions from the community to help get a better sense of what's the lesser of two evils. I see your point of introducing the implicit dependency between protoc and application code, but it is implicit, and won't prevent one from generating the proto java objects, just won't compile afterwards if the declared interface is not present. But the same holds true for having the wrappers, if they are not present in the classpath at compile time, it won't work. This dependency is isolated to a particular VM, but having an interface(s) allows for easier use of objects representing "concepts" without having to resort to reflection. It seems to me that at the end of the day its all about the business needs and convenience, so the less code one has to write and maintain, the better.
Also, can you elaborate (if possible) on why would this not work with Google's internal build system -- 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.
