JSON, anonymous fields, weekly 2-22, issue 3069
Matt Nunogawa
code review 5656102:
http://groups.google.com/group/golang-dev/browse_thread/thread/98b5058988977f21/6d98a0ee1984a17a
https://code.google.com/p/go/issues/detail?id=3069
I'd like to make a case that issue 3069 be changed from Later to Go1
Currently, JSON is the lingua franca of the web. It's also important
for backend stores such as Riak.
I have a nice little CMS that uses Go structs for it's "Model"
architecture. This change (5656102) breaks so many things about my
design.
Here's a typical model definition:
type Common struct {
Pkey string
Added time.Time
Moded time.Time
}
type Book struct {
Common
Title string
Authors []ForeignKey
}
type Author struct {
Common
Name string
Books []ForeignKey
}
type DVD struct {
Common
Title string
Price float
Movie ForeignKey
}
type Movie struct {
Common
Name string
Actors []ForeignKey
}
type Actor struct {
Common
Name string
Movies []ForeignKey
}
etc.
The obvious problem, of not getting the common fields in the structs
is solved by naming the field "Common Common" or alternatively pasting
Pkey, Added, Moded into every struct. This is irritating, but
tolerable.
The part that really hurts is that without support for anonymous
fields in JSON, I lose the ability to easily implement common methods
across great swaths of structs like so:
type ModelStructInterface interface {
GetPrimaryKey() string
}
func (c *Common) GetPrimaryKey() string {
return c.Pkey
}
My understanding is that structs with anonymous fields inherit their
methods. structs with named fields do not.
Without support for anonymous fields in the json package, I have
resort to this:
type ModelStructInterface interface {
GetPrimaryKey() string
}
func (thing *Book) GetPrimaryKey() string {return thing.Common.Pkey }
func (thing *Author) GetPrimaryKey() string {return
thing.Common.Pkey }
func (thing *DVD) GetPrimaryKey() string {return thing.Common.Pkey }
func (thing *Movie) GetPrimaryKey() string {return thing.Common.Pkey }
func (thing *Actor) GetPrimaryKey() string {return thing.Common.Pkey }
Which of course gets worse and worse the more methods I have in the
ModelStructInterface and the more modelStructs I have...
Is there any chance to reprioritize 3069? I understand the need to
ship Go1. I totally agree that the json package should behave like
the xml package (in fact the behavior in weekly 2012-02-07 was
surprising). Yet, anonymous fields are a tremendously important part
of reusing code in Go. If Go1 ships without support for anonymous
fields, I'd have to resort to workarounds or fork the built-in json
encoder. Neither is a particularly appealing option.
Lastly, if I am missing something obvious, please, please tell me.
I'd love almost any solution where I don't have to implement
GetPrimaryKey for 30 different structs.
David Symonds
> Is there any chance to reprioritize 3069?
There's almost no chance. It's going to suck for you right now, but
there's every possibility that it will be fixed in Go 1.1.
Dave.
Sascha Matzke
--
Through the darkness of future past
the magician longs to see
One chants out between two worlds
Fire walk with me.
Johann Höchtl
- Johann
Gustavo Niemeyer
> It has been decided that JSON should mimic XML encoding in this respect,
> which doesn't serialize anonymous fields either. Unfortunate, as they feel
> second class citizens.
That's not correct. The xml package does serialize anonymous fields,
and the json marshaling of anonymous fields was dropped so that it
does marshaling the same way, by embedding the fields from the
anonymous field.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I'm not absolutely sure of anything.
Matt N
A couple followups:
1) Is Go 1.1 planned for a 2012 release?
2) If I or someone else were to implement embedded anon fields in the
json package, does that help my chances?
David Symonds
> 2) If I or someone else were to implement embedded anon fields in the
> json package, does that help my chances?
It would not be accepted into the standard Go tree for Go 1. You are
welcome to fork the encoding/json package and make changes there,
however.
Dave.
Russ Cox
> This change came out of nowhere and broke my code.
I'm sorry about that. In our defense, we broke your code
so that when we implement anonymous fields better later
(omitting the "Common": { ... } wrapping from the encoding),
it won't break your code then.
It is far better for us to break everything now and then stop
than to break things slowly for a longer period of time.
Part of the deal with Go 1 is that we are, as much as possible,
promising not to break your programs with Go 1.1 and so on.
But getting to something we're comfortable guaranteeing has
required a lot of churn; I expect that many more significant things
have also broken in your programs.
Russ