JSON, anonymous fields, weekly 2-22, issue 3069

Showing 1-8 of 8 messages
JSON, anonymous fields, weekly 2-22, issue 3069 Matt N 3/3/12 4:00 PM
The background changes and issues:

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.
Re: [go-nuts] JSON, anonymous fields, weekly 2-22, issue 3069 David Symonds 3/3/12 5:21 PM
On Sun, Mar 4, 2012 at 11:00 AM, Matt Nunogawa <mtn...@gmail.com> wrote:

> 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.

Re: [go-nuts] JSON, anonymous fields, weekly 2-22, issue 3069 Sascha Matzke 3/4/12 1:08 AM
I second this...

This change came out of nowhere and broke my code.

Like Matt I was relying on a well-documented language feature (anonymous fields) and just because my storage backend and client frontend are JSON I can't anymore.

From my point of view this seems to be a little bit too drastic for a last minute change.

For now I'm stuck with an in between Go version until this is fixed. Until this is resolved, Go 1 is a no go for me. Let's hope for Go 1.1.

Sascha
--
Through the darkness of future past
the magician longs to see
One chants out between two worlds
Fire walk with me.

Re: JSON, anonymous fields, weekly 2-22, issue 3069 Johann Höchtl 3/4/12 2:04 AM
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.

- Johann
Re: [go-nuts] Re: JSON, anonymous fields, weekly 2-22, issue 3069 Gustavo Niemeyer 3/4/12 2:23 AM
On Sun, Mar 4, 2012 at 07:04, Johann Höchtl <johann....@gmail.com> wrote:
> 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.

Re: JSON, anonymous fields, weekly 2-22, issue 3069 Matt N 3/4/12 1:39 PM
Thanks for the honest, direct feedback.

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?
Re: [go-nuts] Re: JSON, anonymous fields, weekly 2-22, issue 3069 David Symonds 3/4/12 1:48 PM
On Mon, Mar 5, 2012 at 8:39 AM, Matt N <mtn...@gmail.com> wrote:

> 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.

Re: [go-nuts] JSON, anonymous fields, weekly 2-22, issue 3069 Russ Cox 3/8/12 8:14 AM
On Sun, Mar 4, 2012 at 04:08, Sascha Matzke <sascha...@didolo.org> wrote:
> 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