FAQ
LGTM as is.

I don't want to introduce special cases. The behavior of

type T struct {
X int
Y int
Z int
w int
}

should not change if you remove X, Y, or Z individually, and it does
not. If you remove all three, it should not change either.


https://codereview.appspot.com/7139049/

Search Discussions

  • Rsc at Jan 22, 2013 at 10:49 pm
    *** Submitted as
    https://code.google.com/p/go/source/detail?r=9439d60e0f96 ***

    encoding/json: ignore unexported fields in Unmarshal

    Go 1.0 behavior was to create an UnmarshalFieldError when a json value
    name matched an unexported field name. This error will no longer be
    created and the field will be skipped instead.

    Fixes issue 4660.

    R=adg, rsc, bradfitz
    CC=golang-dev
    https://codereview.appspot.com/7139049

    Committer: Russ Cox <rsc@golang.org>


    https://codereview.appspot.com/7139049/
  • Brad Fitzpatrick at Jan 22, 2013 at 11:13 pm

    On Tue, Jan 22, 2013 at 2:48 PM, wrote:

    LGTM as is.

    I don't want to introduce special cases. The behavior of

    type T struct {
    X int
    Y int
    Z int
    w int
    }

    should not change if you remove X, Y, or Z individually, and it does
    not. If you remove all three, it should not change either.
    I guess.

    But if there are no exported fields, why are they unmarshalling in the
    first place?

    I actually don't really care much either way.
  • Andrew Gerrand at Jan 23, 2013 at 1:11 am

    On 23 January 2013 09:48, wrote:

    I don't want to introduce special cases. The behavior of

    type T struct {
    X int
    Y int
    Z int
    w int
    }

    should not change if you remove X, Y, or Z individually, and it does
    not. If you remove all three, it should not change either.
    I understand the desire not to introduce special cases.

    However, calling unmarshal on a data structure that can never receive any
    of the data seems like it is always a mistake to me. And it's a mistake
    that pretty much only newbies will make.

    I'm not averse to improving this with better docs though.
  • Russ Cox at Jan 23, 2013 at 2:51 am
    If you do it for a struct passed directly into Unmarshal/Marshal - not for
    any of its subfields, and not if it has methods - then that's probably
    okay. What I want to avoid is bombs in the code that only go off if you
    happen to get to the right place in a complex data structure.
  • Andrew Gerrand at Jan 23, 2013 at 3:01 am
    LGTM
    On 23 January 2013 13:51, Russ Cox wrote:

    If you do it for a struct passed directly into Unmarshal/Marshal - not for
    any of its subfields, and not if it has methods - then that's probably
    okay. What I want to avoid is bombs in the code that only go off if you
    happen to get to the right place in a complex data structure.

    Good call. Let's do this in a follow up CL, if at all.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJan 22, '13 at 10:48p
activeJan 23, '13 at 3:01a
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase