json: omitempty => omitzero
Gustavo Niemeyer
As minor nit, it sounds like the new "omitempty" option in the json
package would be better suited as "omitzero", since it's really acting
on what we call "zero values". Is there still time to change this?
Also taking that chance, what's the syntax for a tag that has more
than one such option? The json package only has one at the moment,
and it's not clear from the docs or code what would be the follow up
on that. I'm wondering mostly to build similar packages, rather than
to extend json right now.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I never filed a patent.
David Symonds
> As minor nit, it sounds like the new "omitempty" option in the json
> package would be better suited as "omitzero", since it's really acting
> on what we call "zero values". Is there still time to change this?
That question came up in the review:
http://groups.google.com/group/golang-dev/browse_thread/thread/5c512873af7aeff5
I would have gone for "omitzero" myself, but as rsc pointed out it's
not exactly checking for zero values.
> Also taking that chance, what's the syntax for a tag that has more
> than one such option? The json package only has one at the moment,
> and it's not clear from the docs or code what would be the follow up
> on that. I'm wondering mostly to build similar packages, rather than
> to extend json right now.
It's up to each package. JSON actually has two options,
comma-separated. The protocol buffer package has several more options,
also comma-separated. That seems like a bit of a precedent, but each
namespace can determine whatever makes most sense.
Dave.
Gustavo Niemeyer
Oops.. sounds too late then.
> I would have gone for "omitzero" myself, but as rsc pointed out it's
> not exactly checking for zero values.
Yeah, I'd go with omitzero as well, as it's checking for the zero
values on all types it acts upon.
> It's up to each package. JSON actually has two options,
> comma-separated. The protocol buffer package has several more options,
> also comma-separated. That seems like a bit of a precedent, but each
Understood. I was seeing it as a name and a flag, and there was an
open question about whether more flags might be in the same side of
the comma joined by e.g. spaces, making the flag field positional, or
joined by additional commas. Given your point about protobuffers,
I'll take it as the latter.
> namespace can determine whatever makes most sense.
That was my impression as well. Just trying to follow existing conventions.
Thanks for the details.
David Symonds
>> That question came up in the review:
>
> Oops.. sounds too late then.
I wouldn't necessarily say that. It's not like Go is static once it's
been committed. ;-)
>> I would have gone for "omitzero" myself, but as rsc pointed out it's
>> not exactly checking for zero values.
>
> Yeah, I'd go with omitzero as well, as it's checking for the zero
> values on all types it acts upon.
But that's not accurate. An allocated slice with len == 0 is not that
type's zero value, but omitempty will exclude it, which is usually
what you want. Same for maps, etc.
Dave.
Gustavo Niemeyer
> type's zero value, but omitempty will exclude it, which is usually
> what you want. Same for maps, etc.
That's true. There are imperfections in the analogy going both ways.
I guess I'd personally be happier in calling an allocated empty slice
as zero, than a zero int as empty. Either way, I'll follow the same
convention on other packages if omitempty is what's been decided.
Also, from another perspective, when I first introduced this idea on
gobson, the term was "conditional", but with a single letter "c", so
any of those is really an improvement in terms of clarity.
Gustavo Niemeyer
> gobson, the term was "conditional", but with a single letter "c", so
> any of those is really an improvement in terms of clarity.
FWIW, while patching the code to the new convention this doesn't feel
like such a great idea anymore. The "/c" flag is very used in
practice with gobson types, and translating it to ",omitempty" across
the board feels too verbose. I'll end up just switching from "/c" to
",c" to at least get closer to the new convention.
Russ Cox
over ",omitempty".
Gustavo Niemeyer
> over ",omitempty".
The point made was exactly the opposite. omitempty is an improvement
in clarity.
The result of all the changes is somewhat displeasing, though:
type indexSpec struct {
Unique bool `bson:",omitempty"`
DropDups bool `bson:"dropDups,omitempty"`
Background bool `bson:",omitempty"`
Sparse bool `bson:",omitempty"`
Bits, Min, Max int `bson:",omitempty"`
}
Where I had this:
type indexSpec struct {
Unique bool ",c"
DropDups bool ",c"
Background bool "dropDups,c"
Sparse bool ",c"
Bits, Min, Max int ",c"
Russ Cox
It seems better to be clear about who is being
talked to (the bson:) and what is meant (the ,omitempty).
Russ
Gustavo Niemeyer
> It seems better to be clear about who is being
> talked to (the bson:) and what is meant (the ,omitempty).
It turns out to be fairly common in a schema-free document database
such as MongoDB. I had my mind set to switch to omitempty, but while
doing all the conversions, it really started to feel bad in practice.
For the moment, it will support the "bson:" namespace and the public
types will use it, will switch from the current "/c" to ",c", but will
keep the current flags. Let's see how people feel. We can always
switch over in the future.