Updates:
Owner: ken...@google.com
Comment #40 on issue 57 by ken...@google.com: null values should be treated
as no value
http://code.google.com/p/protobuf/issues/detail?id=57
OK, look: The vast majority of the people I talk to about this agree that
the
current behavior is correct. Of course, these people, being happy with the
status
quo, don't usually come out to argue about it, which is why you see mostly
complaints
on this thread.
Now, I'd of course like to find a solution that pleases everybody.
However, I note
the following:
- After a successful call to setFoo(x), getFoo() should return x. I refuse
to
implement anything in which this is not the case.
- If getFoo() returns x before serialization, then after serializing and
re-parsing
the message, it must still return x. I refuse to implement anything in
which this is
not the case.
- There is no "null" in the protocol buffers encoding. We cannot add one
as not only
would it break compatibility, but it simply would not work in some other
languages.
In C++, for example, the getters return references, which cannot be null.
Some
languages have no concept of null at all.
- A major reason why there is no "null" is because it would tend to lead to
security
problems. If getFoo() could return null, and some caller failed to check
for that,
then it would be trivial for an attacker to exploit that by sending a null
value.
But, such problems could easily pass normal testing if the test clients
never happen
to send null values, which could easily be the case for many apps. This
would be
especially problematic for C++ servers.
- Having getFoo() return null when hasFoo() is false would obviously lead
to the same
problems. Additionally, it would break lots of existing code, and would
disappoint
many people who like the fact that they can write
"getFoo().getBar().getBaz().hasQux()" without having to check hasFoo(),
hasBar(), or
hasBaz() explicitly.
Therefore we simply cannot have setFoo(null) do anything except throw NPE.
Now, what can we do instead? I am open to the idea of introducing a
setOrClearFoo()
accessor which has the behavior you want. Some open questions about this:
- How much will this increase generated code size? Note that code size is
a huge
problem for protocol buffers at present. The overhead would have to be no
more than
a percent or two.
- Should primitive fields also get a setOrClearFoo() accessor, taking the
boxed type
as the input?
So far no one has sent me a patch implementing this or examining the code
size issue.
Sorry, I don't have time to write it myself.
Note that as of version 2.3.0, you could actually implement setOrClearFoo()
via a
code generator plugin which inserts code into the classes generated by
protoc. See:
http://code.google.com/apis/protocolbuffers/docs/reference/other.html
http://code.google.com/apis/protocolbuffers/docs/reference/java-
generated.html#plugins
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
