Comment #2 on issue 451 by Make SingleFieldBuilder truly extendable.

Well, I've implemented a DynamicMessage and DynamicMessage.Builder like
classes to provide the same functionality plus all sub-builders might have
parents as is the case with GeneratedMessage.Builder(-s).
This is a major use-case not covered by DynamicMessage.Builder. It can be
done as efficiently as with the concrete GeneratedMessage.Builder, but I
felt I've been going through the minefield trying to extends anything.
My implementation is based on GeneratedMessage/Builder and
SingleField/RepeatedFieldBuilder because it is already providing this
functionality. It involves a lot of dancing around final, package-private
and the likes.
If I knew that this would not be rejected, I would gladly provide the code
within the protobuf package, and so would avoid a lot of nastiness and
workarounds in it. This code looks like more efficient than DynamicMessage
one, and also would be very similar to the generated codebase.

Last year, during the last week of my contract @Google, I tried to
implement Protobuf OGNL extension; almost done that, and then realized that
DynamicMessage doesn't support BuilderParent. So this is my comeback to the
issue; tried hard many different pathways. The implementation is completed,
but I am trying to make it as efficient as possible, and want to avoid any
workaround wrappers and such. Basically, I've merge DynamicMessage code and
ideas with the generated GeneratedMessage.

Again, if I knew that this idea and contribution would be welcome, I'd
change a bit my existing implementation and commit this code. Otherwise, my
plan is to go on with less efficient one on top of GeneratedMessage and use
it as part of my ProtoBuf/OGNL extension.

Please let me know your thoughts.

You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to