Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Kaveh Shahbazian]

You are right Axel, I should be more clear on when one needs to overwrite 
that method with the same name as type (with the same name) (method B of 
type *B).

Sample: https://play.golang.org/p/rg5C_5Z5NhR (compiler error)

Working example using type aliases: https://play.golang.org/p/PBHBvkSPUxW

On Wednesday, February 28, 2018 at 11:00:13 PM UTC+3:30, Axel Wagner wrote:
>
> Can you elaborate/link to example code? Because it seems to work just fine 
> .
>
>
> On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian  > wrote:
>
>> BTW I have found an interesting usage for embedding type aliases. Assume 
>> a type A embeds another type B that has a member named B. That will cause a 
>> compilation error since A has two members named B. Now if a type alias be 
>> defined as type OrigB = B, then A can embed OrigB without any problems.
>>
>> On Tuesday, January 23, 2018 at 9:59:10 PM UTC+3:30, Kaveh Shahbazian 
>> wrote:
>>>
>>> Did not try that and changed that instance of this code.
>>>
>>> On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote:

 Have you tried out the behaviour on Go tip (or the go 1.10 beta)?

 On 23 Jan 2018 14:31, "Josh Humphries"  wrote:

 Roger,
 I don't believe that patch will change behavior. See my last message: 
 the fields appear to be unexported according to reflection.

 That patch has the encoding/json package checking StructField.PkgPath, 
 which should be blank for exported fields. For these fields, it is 
 "go.builtin", which appears to be a pseudo-package name for builtins 
 (interestingly, it's not just "builtin" which is what Go doc would lead 
 one 
 to expect). That means it will behave the same and skip the three fields 
 in 
 question.

  This is non-intuitive based on the language spec, since the field 
 names are upper-cased. I think this is either a bug in reflect -- which 
 should set StructField.PkgPath to "" since the field name is exported -- 
 OR 
 a bug in the compiler which should complain that there are three fields 
 whose resolved name appears to be the unexported identifier "int".


 

 Josh Humphries

 FullStory   |  Atlanta, GA

 Software Engineer

 j...@fullstory.com

 On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  wrote:

> This is a bug that has been fixed on Go tip by
> https://go-review.googlesource.com/c/go/+/65550.
>
>
> On 23 January 2018 at 00:45, Josh Humphries  
> wrote:
> > I think have misspoken. Even though the field's name appears 
> exported via
> > reflection (it has a name that starts with a capital letter), 
> attempting to
> > use the reflect.Value's SetInt method panics, indicating that the 
> field was
> > obtained using an unexported field. So the encoding/json package is 
> thus
> > consistent with that in that it ignores unexported fields.
> >
> > It is still not obvious from the spec what should be happening. I 
> would
> > expect it to be exported due to the resolved field name. But if it is
> > unexported because the compiler resolves the alias first, then I 
> would
> > expect a compiler error because the four fields all resolve to the 
> same
> > name. The spec states this is not allowed:
> >
> > The following declaration is illegal because field names must be 
> unique in a
> > struct type:
> >
> > struct {
> >   T // conflicts with embedded field *T and *P.T
> >   *T// conflicts with embedded field T and *P.T
> >   *P.T  // conflicts with embedded field T and *T
> > }
> >
> > So it is possible that this is not a bug in the encoding/json 
> package but in
> > the compiler.
> >
> > 
> > Josh Humphries
> > jh...@bluegosling.com
> >
> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries <
> jh...@bluegosling.com>
> > wrote:
> >>
> >> I think that is expected, and it is the JSON marshaling that is 
> surprising
> >> (and erroneous).
> >>
> >> If it were expected that the embed field names resolved to the alias
> >> target type name, it would instead be a compiler error since the 
> compiler
> >> does not allow embedded types that would result in name collisions. 
> Using
> >> reflection, one can see the fields are named just as in your 
> example, after
> >> the type aliases, not its underlying type name. The bug is that JSON
> >> marshaling is not looking at the field name and instead looking 
> directly at
> >> the field type name (which, in this case, has been resolved to int).
> >>
> >> 
> >> Josh Humphries
> >> jh...@bluegosling.com
> >>
> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
> >>  wrote:
>

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

['Axel Wagner' via golang-nuts]

Can you elaborate/link to example code? Because it seems to work just fine
.


On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian 
wrote:

> BTW I have found an interesting usage for embedding type aliases. Assume a
> type A embeds another type B that has a member named B. That will cause a
> compilation error since A has two members named B. Now if a type alias be
> defined as type OrigB = B, then A can embed OrigB without any problems.
>
> On Tuesday, January 23, 2018 at 9:59:10 PM UTC+3:30, Kaveh Shahbazian
> wrote:
>>
>> Did not try that and changed that instance of this code.
>>
>> On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote:
>>>
>>> Have you tried out the behaviour on Go tip (or the go 1.10 beta)?
>>>
>>> On 23 Jan 2018 14:31, "Josh Humphries"  wrote:
>>>
>>> Roger,
>>> I don't believe that patch will change behavior. See my last message:
>>> the fields appear to be unexported according to reflection.
>>>
>>> That patch has the encoding/json package checking StructField.PkgPath,
>>> which should be blank for exported fields. For these fields, it is
>>> "go.builtin", which appears to be a pseudo-package name for builtins
>>> (interestingly, it's not just "builtin" which is what Go doc would lead one
>>> to expect). That means it will behave the same and skip the three fields in
>>> question.
>>>
>>>  This is non-intuitive based on the language spec, since the field names
>>> are upper-cased. I think this is either a bug in reflect -- which should
>>> set StructField.PkgPath to "" since the field name is exported -- OR a bug
>>> in the compiler which should complain that there are three fields whose
>>> resolved name appears to be the unexported identifier "int".
>>>
>>>
>>> 
>>>
>>> Josh Humphries
>>>
>>> FullStory   |  Atlanta, GA
>>>
>>> Software Engineer
>>>
>>> j...@fullstory.com
>>>
>>> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  wrote:
>>>
 This is a bug that has been fixed on Go tip by
 https://go-review.googlesource.com/c/go/+/65550.


 On 23 January 2018 at 00:45, Josh Humphries 
 wrote:
 > I think have misspoken. Even though the field's name appears exported
 via
 > reflection (it has a name that starts with a capital letter),
 attempting to
 > use the reflect.Value's SetInt method panics, indicating that the
 field was
 > obtained using an unexported field. So the encoding/json package is
 thus
 > consistent with that in that it ignores unexported fields.
 >
 > It is still not obvious from the spec what should be happening. I
 would
 > expect it to be exported due to the resolved field name. But if it is
 > unexported because the compiler resolves the alias first, then I would
 > expect a compiler error because the four fields all resolve to the
 same
 > name. The spec states this is not allowed:
 >
 > The following declaration is illegal because field names must be
 unique in a
 > struct type:
 >
 > struct {
 >   T // conflicts with embedded field *T and *P.T
 >   *T// conflicts with embedded field T and *P.T
 >   *P.T  // conflicts with embedded field T and *T
 > }
 >
 > So it is possible that this is not a bug in the encoding/json package
 but in
 > the compiler.
 >
 > 
 > Josh Humphries
 > jh...@bluegosling.com
 >
 > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries <
 jh...@bluegosling.com>
 > wrote:
 >>
 >> I think that is expected, and it is the JSON marshaling that is
 surprising
 >> (and erroneous).
 >>
 >> If it were expected that the embed field names resolved to the alias
 >> target type name, it would instead be a compiler error since the
 compiler
 >> does not allow embedded types that would result in name collisions.
 Using
 >> reflection, one can see the fields are named just as in your
 example, after
 >> the type aliases, not its underlying type name. The bug is that JSON
 >> marshaling is not looking at the field name and instead looking
 directly at
 >> the field type name (which, in this case, has been resolved to int).
 >>
 >> 
 >> Josh Humphries
 >> jh...@bluegosling.com
 >>
 >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
 >>  wrote:
 >>>
 >>> This is sort of surprising though:
 https://play.golang.org/p/mjfkzIqAo_b
 >>>
 >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
 >>> > From the Language Specification -
 >>> >
 >>> > A field declared with a type but no explicit field name is called
 an
 >>> > *embedded
 >>> > field*. An embedded field must be specified as a type name T or
 as a
 >>> > pointer to a non-interface type name *T, and T itself may not be a
 >>> > pointer
 >>> > type. The unqualified type name acts as 

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Kaveh Shahbazian]

BTW I have found an interesting usage for embedding type aliases. Assume a 
type A embeds another type B that has a member named B. That will cause a 
compilation error since A has two members named B. Now if a type alias be 
defined as type OrigB = B, then A can embed OrigB without any problems.

On Tuesday, January 23, 2018 at 9:59:10 PM UTC+3:30, Kaveh Shahbazian wrote:
>
> Did not try that and changed that instance of this code.
>
> On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote:
>>
>> Have you tried out the behaviour on Go tip (or the go 1.10 beta)?
>>
>> On 23 Jan 2018 14:31, "Josh Humphries"  wrote:
>>
>> Roger,
>> I don't believe that patch will change behavior. See my last message: the 
>> fields appear to be unexported according to reflection.
>>
>> That patch has the encoding/json package checking StructField.PkgPath, 
>> which should be blank for exported fields. For these fields, it is 
>> "go.builtin", which appears to be a pseudo-package name for builtins 
>> (interestingly, it's not just "builtin" which is what Go doc would lead one 
>> to expect). That means it will behave the same and skip the three fields in 
>> question.
>>
>>  This is non-intuitive based on the language spec, since the field names 
>> are upper-cased. I think this is either a bug in reflect -- which should 
>> set StructField.PkgPath to "" since the field name is exported -- OR a bug 
>> in the compiler which should complain that there are three fields whose 
>> resolved name appears to be the unexported identifier "int".
>>
>>
>> 
>>
>> Josh Humphries
>>
>> FullStory   |  Atlanta, GA
>>
>> Software Engineer
>>
>> j...@fullstory.com
>>
>> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  wrote:
>>
>>> This is a bug that has been fixed on Go tip by
>>> https://go-review.googlesource.com/c/go/+/65550.
>>>
>>>
>>> On 23 January 2018 at 00:45, Josh Humphries  
>>> wrote:
>>> > I think have misspoken. Even though the field's name appears exported 
>>> via
>>> > reflection (it has a name that starts with a capital letter), 
>>> attempting to
>>> > use the reflect.Value's SetInt method panics, indicating that the 
>>> field was
>>> > obtained using an unexported field. So the encoding/json package is 
>>> thus
>>> > consistent with that in that it ignores unexported fields.
>>> >
>>> > It is still not obvious from the spec what should be happening. I would
>>> > expect it to be exported due to the resolved field name. But if it is
>>> > unexported because the compiler resolves the alias first, then I would
>>> > expect a compiler error because the four fields all resolve to the same
>>> > name. The spec states this is not allowed:
>>> >
>>> > The following declaration is illegal because field names must be 
>>> unique in a
>>> > struct type:
>>> >
>>> > struct {
>>> >   T // conflicts with embedded field *T and *P.T
>>> >   *T// conflicts with embedded field T and *P.T
>>> >   *P.T  // conflicts with embedded field T and *T
>>> > }
>>> >
>>> > So it is possible that this is not a bug in the encoding/json package 
>>> but in
>>> > the compiler.
>>> >
>>> > 
>>> > Josh Humphries
>>> > jh...@bluegosling.com
>>> >
>>> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries >> >
>>> > wrote:
>>> >>
>>> >> I think that is expected, and it is the JSON marshaling that is 
>>> surprising
>>> >> (and erroneous).
>>> >>
>>> >> If it were expected that the embed field names resolved to the alias
>>> >> target type name, it would instead be a compiler error since the 
>>> compiler
>>> >> does not allow embedded types that would result in name collisions. 
>>> Using
>>> >> reflection, one can see the fields are named just as in your example, 
>>> after
>>> >> the type aliases, not its underlying type name. The bug is that JSON
>>> >> marshaling is not looking at the field name and instead looking 
>>> directly at
>>> >> the field type name (which, in this case, has been resolved to int).
>>> >>
>>> >> 
>>> >> Josh Humphries
>>> >> jh...@bluegosling.com
>>> >>
>>> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>>> >>  wrote:
>>> >>>
>>> >>> This is sort of surprising though: 
>>> https://play.golang.org/p/mjfkzIqAo_b
>>> >>>
>>> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>>> >>> > From the Language Specification -
>>> >>> >
>>> >>> > A field declared with a type but no explicit field name is called 
>>> an
>>> >>> > *embedded
>>> >>> > field*. An embedded field must be specified as a type name T or as 
>>> a
>>> >>> > pointer to a non-interface type name *T, and T itself may not be a
>>> >>> > pointer
>>> >>> > type. The unqualified type name acts as the field name.
>>> >>> >
>>> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>>> >>> > *P.T4
>>> >>> > struct {
>>> >>> > T1// field name is T1
>>> >>> > *T2   // field name is T2
>>> >>> > P.T3  // field name is T3
>>> >>> > *P.T4 // fiel

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[dc0d]

Did not try that and changed that instance of this code.

On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote:
>
> Have you tried out the behaviour on Go tip (or the go 1.10 beta)?
>
> On 23 Jan 2018 14:31, "Josh Humphries" > 
> wrote:
>
> Roger,
> I don't believe that patch will change behavior. See my last message: the 
> fields appear to be unexported according to reflection.
>
> That patch has the encoding/json package checking StructField.PkgPath, 
> which should be blank for exported fields. For these fields, it is 
> "go.builtin", which appears to be a pseudo-package name for builtins 
> (interestingly, it's not just "builtin" which is what Go doc would lead one 
> to expect). That means it will behave the same and skip the three fields in 
> question.
>
>  This is non-intuitive based on the language spec, since the field names 
> are upper-cased. I think this is either a bug in reflect -- which should 
> set StructField.PkgPath to "" since the field name is exported -- OR a bug 
> in the compiler which should complain that there are three fields whose 
> resolved name appears to be the unexported identifier "int".
>
>
> 
>
> Josh Humphries
>
> FullStory   |  Atlanta, GA
>
> Software Engineer
>
> j...@fullstory.com 
>
> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  > wrote:
>
>> This is a bug that has been fixed on Go tip by
>> https://go-review.googlesource.com/c/go/+/65550.
>>
>>
>> On 23 January 2018 at 00:45, Josh Humphries > > wrote:
>> > I think have misspoken. Even though the field's name appears exported 
>> via
>> > reflection (it has a name that starts with a capital letter), 
>> attempting to
>> > use the reflect.Value's SetInt method panics, indicating that the field 
>> was
>> > obtained using an unexported field. So the encoding/json package is thus
>> > consistent with that in that it ignores unexported fields.
>> >
>> > It is still not obvious from the spec what should be happening. I would
>> > expect it to be exported due to the resolved field name. But if it is
>> > unexported because the compiler resolves the alias first, then I would
>> > expect a compiler error because the four fields all resolve to the same
>> > name. The spec states this is not allowed:
>> >
>> > The following declaration is illegal because field names must be unique 
>> in a
>> > struct type:
>> >
>> > struct {
>> >   T // conflicts with embedded field *T and *P.T
>> >   *T// conflicts with embedded field T and *P.T
>> >   *P.T  // conflicts with embedded field T and *T
>> > }
>> >
>> > So it is possible that this is not a bug in the encoding/json package 
>> but in
>> > the compiler.
>> >
>> > 
>> > Josh Humphries
>> > jh...@bluegosling.com 
>> >
>> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries > >
>> > wrote:
>> >>
>> >> I think that is expected, and it is the JSON marshaling that is 
>> surprising
>> >> (and erroneous).
>> >>
>> >> If it were expected that the embed field names resolved to the alias
>> >> target type name, it would instead be a compiler error since the 
>> compiler
>> >> does not allow embedded types that would result in name collisions. 
>> Using
>> >> reflection, one can see the fields are named just as in your example, 
>> after
>> >> the type aliases, not its underlying type name. The bug is that JSON
>> >> marshaling is not looking at the field name and instead looking 
>> directly at
>> >> the field type name (which, in this case, has been resolved to int).
>> >>
>> >> 
>> >> Josh Humphries
>> >> jh...@bluegosling.com 
>> >>
>> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>> >> > wrote:
>> >>>
>> >>> This is sort of surprising though: 
>> https://play.golang.org/p/mjfkzIqAo_b
>> >>>
>> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>> >>> > From the Language Specification -
>> >>> >
>> >>> > A field declared with a type but no explicit field name is called an
>> >>> > *embedded
>> >>> > field*. An embedded field must be specified as a type name T or as a
>> >>> > pointer to a non-interface type name *T, and T itself may not be a
>> >>> > pointer
>> >>> > type. The unqualified type name acts as the field name.
>> >>> >
>> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>> >>> > *P.T4
>> >>> > struct {
>> >>> > T1// field name is T1
>> >>> > *T2   // field name is T2
>> >>> > P.T3  // field name is T3
>> >>> > *P.T4 // field name is T4
>> >>> > x, y int  // field names are x and y
>> >>> > }
>> >>> >
>> >>> >
>> >>> > From the encoding/json#Marshal documentation -
>> >>> >
>> >>> > Struct values encode as JSON objects. Each exported struct field
>> >>> > becomes a
>> >>> > member of the object, using the field name as the object key, unless
>> >>> > the
>> >>> > field is omitted for one of the reasons given below.
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google 
>>

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[roger peppe]

Have you tried out the behaviour on Go tip (or the go 1.10 beta)?

On 23 Jan 2018 14:31, "Josh Humphries"  wrote:

Roger,
I don't believe that patch will change behavior. See my last message: the
fields appear to be unexported according to reflection.

That patch has the encoding/json package checking StructField.PkgPath,
which should be blank for exported fields. For these fields, it is
"go.builtin", which appears to be a pseudo-package name for builtins
(interestingly, it's not just "builtin" which is what Go doc would lead one
to expect). That means it will behave the same and skip the three fields in
question.

 This is non-intuitive based on the language spec, since the field names
are upper-cased. I think this is either a bug in reflect -- which should
set StructField.PkgPath to "" since the field name is exported -- OR a bug
in the compiler which should complain that there are three fields whose
resolved name appears to be the unexported identifier "int".




Josh Humphries

FullStory   |  Atlanta, GA

Software Engineer

j...@fullstory.com

On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  wrote:

> This is a bug that has been fixed on Go tip by
> https://go-review.googlesource.com/c/go/+/65550.
>
>
> On 23 January 2018 at 00:45, Josh Humphries  wrote:
> > I think have misspoken. Even though the field's name appears exported via
> > reflection (it has a name that starts with a capital letter), attempting
> to
> > use the reflect.Value's SetInt method panics, indicating that the field
> was
> > obtained using an unexported field. So the encoding/json package is thus
> > consistent with that in that it ignores unexported fields.
> >
> > It is still not obvious from the spec what should be happening. I would
> > expect it to be exported due to the resolved field name. But if it is
> > unexported because the compiler resolves the alias first, then I would
> > expect a compiler error because the four fields all resolve to the same
> > name. The spec states this is not allowed:
> >
> > The following declaration is illegal because field names must be unique
> in a
> > struct type:
> >
> > struct {
> >   T // conflicts with embedded field *T and *P.T
> >   *T// conflicts with embedded field T and *P.T
> >   *P.T  // conflicts with embedded field T and *T
> > }
> >
> > So it is possible that this is not a bug in the encoding/json package
> but in
> > the compiler.
> >
> > 
> > Josh Humphries
> > jh...@bluegosling.com
> >
> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries 
> > wrote:
> >>
> >> I think that is expected, and it is the JSON marshaling that is
> surprising
> >> (and erroneous).
> >>
> >> If it were expected that the embed field names resolved to the alias
> >> target type name, it would instead be a compiler error since the
> compiler
> >> does not allow embedded types that would result in name collisions.
> Using
> >> reflection, one can see the fields are named just as in your example,
> after
> >> the type aliases, not its underlying type name. The bug is that JSON
> >> marshaling is not looking at the field name and instead looking
> directly at
> >> the field type name (which, in this case, has been resolved to int).
> >>
> >> 
> >> Josh Humphries
> >> jh...@bluegosling.com
> >>
> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
> >>  wrote:
> >>>
> >>> This is sort of surprising though: https://play.golang.org/p/mjfk
> zIqAo_b
> >>>
> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
> >>> > From the Language Specification -
> >>> >
> >>> > A field declared with a type but no explicit field name is called an
> >>> > *embedded
> >>> > field*. An embedded field must be specified as a type name T or as a
> >>> > pointer to a non-interface type name *T, and T itself may not be a
> >>> > pointer
> >>> > type. The unqualified type name acts as the field name.
> >>> >
> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
> >>> > *P.T4
> >>> > struct {
> >>> > T1// field name is T1
> >>> > *T2   // field name is T2
> >>> > P.T3  // field name is T3
> >>> > *P.T4 // field name is T4
> >>> > x, y int  // field names are x and y
> >>> > }
> >>> >
> >>> >
> >>> > From the encoding/json#Marshal documentation -
> >>> >
> >>> > Struct values encode as JSON objects. Each exported struct field
> >>> > becomes a
> >>> > member of the object, using the field name as the object key, unless
> >>> > the
> >>> > field is omitted for one of the reasons given below.
> >>> >
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "golang-nuts" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to golang-nuts+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed t

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[dc0d]

Exactly. That's why I asked before why we are allowed to embed type 
aliases. It should be either not possible, or be properly handled by the 
type system (and tools).

On Tuesday, January 23, 2018 at 6:02:54 PM UTC+3:30, Josh Humphries wrote:
>
> Roger,
> I don't believe that patch will change behavior. See my last message: the 
> fields appear to be unexported according to reflection.
>
> That patch has the encoding/json package checking StructField.PkgPath, 
> which should be blank for exported fields. For these fields, it is 
> "go.builtin", which appears to be a pseudo-package name for builtins 
> (interestingly, it's not just "builtin" which is what Go doc would lead one 
> to expect). That means it will behave the same and skip the three fields in 
> question.
>
>  This is non-intuitive based on the language spec, since the field names 
> are upper-cased. I think this is either a bug in reflect -- which should 
> set StructField.PkgPath to "" since the field name is exported -- OR a bug 
> in the compiler which should complain that there are three fields whose 
> resolved name appears to be the unexported identifier "int".
>
>
> 
>
> Josh Humphries
>
> FullStory   |  Atlanta, GA
>
> Software Engineer
>
> j...@fullstory.com 
>
> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  > wrote:
>
>> This is a bug that has been fixed on Go tip by
>> https://go-review.googlesource.com/c/go/+/65550.
>>
>>
>> On 23 January 2018 at 00:45, Josh Humphries > > wrote:
>> > I think have misspoken. Even though the field's name appears exported 
>> via
>> > reflection (it has a name that starts with a capital letter), 
>> attempting to
>> > use the reflect.Value's SetInt method panics, indicating that the field 
>> was
>> > obtained using an unexported field. So the encoding/json package is thus
>> > consistent with that in that it ignores unexported fields.
>> >
>> > It is still not obvious from the spec what should be happening. I would
>> > expect it to be exported due to the resolved field name. But if it is
>> > unexported because the compiler resolves the alias first, then I would
>> > expect a compiler error because the four fields all resolve to the same
>> > name. The spec states this is not allowed:
>> >
>> > The following declaration is illegal because field names must be unique 
>> in a
>> > struct type:
>> >
>> > struct {
>> >   T // conflicts with embedded field *T and *P.T
>> >   *T// conflicts with embedded field T and *P.T
>> >   *P.T  // conflicts with embedded field T and *T
>> > }
>> >
>> > So it is possible that this is not a bug in the encoding/json package 
>> but in
>> > the compiler.
>> >
>> > 
>> > Josh Humphries
>> > jh...@bluegosling.com 
>> >
>> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries > >
>> > wrote:
>> >>
>> >> I think that is expected, and it is the JSON marshaling that is 
>> surprising
>> >> (and erroneous).
>> >>
>> >> If it were expected that the embed field names resolved to the alias
>> >> target type name, it would instead be a compiler error since the 
>> compiler
>> >> does not allow embedded types that would result in name collisions. 
>> Using
>> >> reflection, one can see the fields are named just as in your example, 
>> after
>> >> the type aliases, not its underlying type name. The bug is that JSON
>> >> marshaling is not looking at the field name and instead looking 
>> directly at
>> >> the field type name (which, in this case, has been resolved to int).
>> >>
>> >> 
>> >> Josh Humphries
>> >> jh...@bluegosling.com 
>> >>
>> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>> >> > wrote:
>> >>>
>> >>> This is sort of surprising though: 
>> https://play.golang.org/p/mjfkzIqAo_b
>> >>>
>> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>> >>> > From the Language Specification -
>> >>> >
>> >>> > A field declared with a type but no explicit field name is called an
>> >>> > *embedded
>> >>> > field*. An embedded field must be specified as a type name T or as a
>> >>> > pointer to a non-interface type name *T, and T itself may not be a
>> >>> > pointer
>> >>> > type. The unqualified type name acts as the field name.
>> >>> >
>> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>> >>> > *P.T4
>> >>> > struct {
>> >>> > T1// field name is T1
>> >>> > *T2   // field name is T2
>> >>> > P.T3  // field name is T3
>> >>> > *P.T4 // field name is T4
>> >>> > x, y int  // field names are x and y
>> >>> > }
>> >>> >
>> >>> >
>> >>> > From the encoding/json#Marshal documentation -
>> >>> >
>> >>> > Struct values encode as JSON objects. Each exported struct field
>> >>> > becomes a
>> >>> > member of the object, using the field name as the object key, unless
>> >>> > the
>> >>> > field is omitted for one of the reasons given below.
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google 
>> Gr

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Josh Humphries]

Roger,
I don't believe that patch will change behavior. See my last message: the
fields appear to be unexported according to reflection.

That patch has the encoding/json package checking StructField.PkgPath,
which should be blank for exported fields. For these fields, it is
"go.builtin", which appears to be a pseudo-package name for builtins
(interestingly, it's not just "builtin" which is what Go doc would lead one
to expect). That means it will behave the same and skip the three fields in
question.

 This is non-intuitive based on the language spec, since the field names
are upper-cased. I think this is either a bug in reflect -- which should
set StructField.PkgPath to "" since the field name is exported -- OR a bug
in the compiler which should complain that there are three fields whose
resolved name appears to be the unexported identifier "int".




Josh Humphries

FullStory   |  Atlanta, GA

Software Engineer

j...@fullstory.com

On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  wrote:

> This is a bug that has been fixed on Go tip by
> https://go-review.googlesource.com/c/go/+/65550.
>
>
> On 23 January 2018 at 00:45, Josh Humphries  wrote:
> > I think have misspoken. Even though the field's name appears exported via
> > reflection (it has a name that starts with a capital letter), attempting
> to
> > use the reflect.Value's SetInt method panics, indicating that the field
> was
> > obtained using an unexported field. So the encoding/json package is thus
> > consistent with that in that it ignores unexported fields.
> >
> > It is still not obvious from the spec what should be happening. I would
> > expect it to be exported due to the resolved field name. But if it is
> > unexported because the compiler resolves the alias first, then I would
> > expect a compiler error because the four fields all resolve to the same
> > name. The spec states this is not allowed:
> >
> > The following declaration is illegal because field names must be unique
> in a
> > struct type:
> >
> > struct {
> >   T // conflicts with embedded field *T and *P.T
> >   *T// conflicts with embedded field T and *P.T
> >   *P.T  // conflicts with embedded field T and *T
> > }
> >
> > So it is possible that this is not a bug in the encoding/json package
> but in
> > the compiler.
> >
> > 
> > Josh Humphries
> > jh...@bluegosling.com
> >
> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries 
> > wrote:
> >>
> >> I think that is expected, and it is the JSON marshaling that is
> surprising
> >> (and erroneous).
> >>
> >> If it were expected that the embed field names resolved to the alias
> >> target type name, it would instead be a compiler error since the
> compiler
> >> does not allow embedded types that would result in name collisions.
> Using
> >> reflection, one can see the fields are named just as in your example,
> after
> >> the type aliases, not its underlying type name. The bug is that JSON
> >> marshaling is not looking at the field name and instead looking
> directly at
> >> the field type name (which, in this case, has been resolved to int).
> >>
> >> 
> >> Josh Humphries
> >> jh...@bluegosling.com
> >>
> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
> >>  wrote:
> >>>
> >>> This is sort of surprising though: https://play.golang.org/p/
> mjfkzIqAo_b
> >>>
> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
> >>> > From the Language Specification -
> >>> >
> >>> > A field declared with a type but no explicit field name is called an
> >>> > *embedded
> >>> > field*. An embedded field must be specified as a type name T or as a
> >>> > pointer to a non-interface type name *T, and T itself may not be a
> >>> > pointer
> >>> > type. The unqualified type name acts as the field name.
> >>> >
> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
> >>> > *P.T4
> >>> > struct {
> >>> > T1// field name is T1
> >>> > *T2   // field name is T2
> >>> > P.T3  // field name is T3
> >>> > *P.T4 // field name is T4
> >>> > x, y int  // field names are x and y
> >>> > }
> >>> >
> >>> >
> >>> > From the encoding/json#Marshal documentation -
> >>> >
> >>> > Struct values encode as JSON objects. Each exported struct field
> >>> > becomes a
> >>> > member of the object, using the field name as the object key, unless
> >>> > the
> >>> > field is omitted for one of the reasons given below.
> >>> >
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "golang-nuts" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to golang-nuts+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, 

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[roger peppe]

This is a bug that has been fixed on Go tip by
https://go-review.googlesource.com/c/go/+/65550.


On 23 January 2018 at 00:45, Josh Humphries  wrote:
> I think have misspoken. Even though the field's name appears exported via
> reflection (it has a name that starts with a capital letter), attempting to
> use the reflect.Value's SetInt method panics, indicating that the field was
> obtained using an unexported field. So the encoding/json package is thus
> consistent with that in that it ignores unexported fields.
>
> It is still not obvious from the spec what should be happening. I would
> expect it to be exported due to the resolved field name. But if it is
> unexported because the compiler resolves the alias first, then I would
> expect a compiler error because the four fields all resolve to the same
> name. The spec states this is not allowed:
>
> The following declaration is illegal because field names must be unique in a
> struct type:
>
> struct {
>   T // conflicts with embedded field *T and *P.T
>   *T// conflicts with embedded field T and *P.T
>   *P.T  // conflicts with embedded field T and *T
> }
>
> So it is possible that this is not a bug in the encoding/json package but in
> the compiler.
>
> 
> Josh Humphries
> jh...@bluegosling.com
>
> On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries 
> wrote:
>>
>> I think that is expected, and it is the JSON marshaling that is surprising
>> (and erroneous).
>>
>> If it were expected that the embed field names resolved to the alias
>> target type name, it would instead be a compiler error since the compiler
>> does not allow embedded types that would result in name collisions. Using
>> reflection, one can see the fields are named just as in your example, after
>> the type aliases, not its underlying type name. The bug is that JSON
>> marshaling is not looking at the field name and instead looking directly at
>> the field type name (which, in this case, has been resolved to int).
>>
>> 
>> Josh Humphries
>> jh...@bluegosling.com
>>
>> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>>  wrote:
>>>
>>> This is sort of surprising though: https://play.golang.org/p/mjfkzIqAo_b
>>>
>>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>>> > From the Language Specification -
>>> >
>>> > A field declared with a type but no explicit field name is called an
>>> > *embedded
>>> > field*. An embedded field must be specified as a type name T or as a
>>> > pointer to a non-interface type name *T, and T itself may not be a
>>> > pointer
>>> > type. The unqualified type name acts as the field name.
>>> >
>>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>>> > *P.T4
>>> > struct {
>>> > T1// field name is T1
>>> > *T2   // field name is T2
>>> > P.T3  // field name is T3
>>> > *P.T4 // field name is T4
>>> > x, y int  // field names are x and y
>>> > }
>>> >
>>> >
>>> > From the encoding/json#Marshal documentation -
>>> >
>>> > Struct values encode as JSON objects. Each exported struct field
>>> > becomes a
>>> > member of the object, using the field name as the object key, unless
>>> > the
>>> > field is omitted for one of the reasons given below.
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Josh Humphries]

I think have misspoken. Even though the field's name appears exported via
reflection (it has a name that starts with a capital letter), attempting to
use the reflect.Value's SetInt method panics, indicating that the field was
obtained using an unexported field. So the encoding/json package is thus
consistent with that in that it ignores unexported fields.

It is still not obvious from the spec what should be happening. I would
expect it to be exported due to the resolved field name. But if it is
unexported because the compiler resolves the alias first, then I would
expect a compiler error because the four fields all resolve to the same
name. The spec  states this is
not allowed:

The following declaration is illegal because field names must be unique in
a struct type:

struct {
T // conflicts with embedded field *T and *P.T
*T// conflicts with embedded field T and *P.T
*P.T  // conflicts with embedded field T and *T
}

So it is possible that this is not a bug in the encoding/json package but
in the compiler.


*Josh Humphries*
jh...@bluegosling.com

On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries 
wrote:

> I think that is expected, and it is the JSON marshaling that is surprising
> (and erroneous).
>
> If it were expected that the embed field names resolved to the alias *target
> type* name, it would instead be a compiler error since the compiler does
> not allow embedded types that would result in name collisions. Using
> reflection, one can see the fields are named just as in your example, after
> the type aliases, not its underlying type name. The bug is that JSON
> marshaling is not looking at the field name and instead looking directly at
> the field type name (which, in this case, has been resolved to int).
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak <
> dan.kortsc...@adelaide.edu.au> wrote:
>
>> This is sort of surprising though: https://play.golang.org/p/mjfkzIqAo_b
>>
>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>> > From the Language Specification -
>> >
>> > A field declared with a type but no explicit field name is called an
>> > *embedded
>> > field*. An embedded field must be specified as a type name T or as a
>> > pointer to a non-interface type name *T, and T itself may not be a
>> > pointer
>> > type. The unqualified type name acts as the field name.
>> >
>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>> > *P.T4
>> > struct {
>> > T1// field name is T1
>> > *T2   // field name is T2
>> > P.T3  // field name is T3
>> > *P.T4 // field name is T4
>> > x, y int  // field names are x and y
>> > }
>> >
>> >
>> > From the encoding/json#Marshal documentation -
>> >
>> > Struct values encode as JSON objects. Each exported struct field
>> > becomes a
>> > member of the object, using the field name as the object key, unless
>> > the
>> > field is omitted for one of the reasons given below.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Dan Kortschak]

The discordance is unexpected.

On Mon, 2018-01-22 at 19:28 -0500, Josh Humphries wrote:
> I think that is expected, and it is the JSON marshaling that is
> surprising
> (and erroneous).
> 
> If it were expected that the embed field names resolved to the alias
> *target
> type* name, it would instead be a compiler error since the compiler
> does
> not allow embedded types that would result in name collisions. Using
> reflection, one can see the fields are named just as in your example,
> after
> the type aliases, not its underlying type name. The bug is that JSON
> marshaling is not looking at the field name and instead looking
> directly at
> the field type name (which, in this case, has been resolved to int).



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Josh Humphries]

I think that is expected, and it is the JSON marshaling that is surprising
(and erroneous).

If it were expected that the embed field names resolved to the alias *target
type* name, it would instead be a compiler error since the compiler does
not allow embedded types that would result in name collisions. Using
reflection, one can see the fields are named just as in your example, after
the type aliases, not its underlying type name. The bug is that JSON
marshaling is not looking at the field name and instead looking directly at
the field type name (which, in this case, has been resolved to int).


*Josh Humphries*
jh...@bluegosling.com

On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> This is sort of surprising though: https://play.golang.org/p/mjfkzIqAo_b
>
> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
> > From the Language Specification -
> >
> > A field declared with a type but no explicit field name is called an
> > *embedded
> > field*. An embedded field must be specified as a type name T or as a
> > pointer to a non-interface type name *T, and T itself may not be a
> > pointer
> > type. The unqualified type name acts as the field name.
> >
> > // A struct with four embedded fields of types T1, *T2, P.T3 and
> > *P.T4
> > struct {
> > T1// field name is T1
> > *T2   // field name is T2
> > P.T3  // field name is T3
> > *P.T4 // field name is T4
> > x, y int  // field names are x and y
> > }
> >
> >
> > From the encoding/json#Marshal documentation -
> >
> > Struct values encode as JSON objects. Each exported struct field
> > becomes a
> > member of the object, using the field name as the object key, unless
> > the
> > field is omitted for one of the reasons given below.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Dan Kortschak]

This is sort of surprising though: https://play.golang.org/p/mjfkzIqAo_b

On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
> From the Language Specification - 
> 
> A field declared with a type but no explicit field name is called an
> *embedded 
> field*. An embedded field must be specified as a type name T or as a 
> pointer to a non-interface type name *T, and T itself may not be a
> pointer 
> type. The unqualified type name acts as the field name.
> 
> // A struct with four embedded fields of types T1, *T2, P.T3 and
> *P.T4
> struct {
> T1// field name is T1
> *T2   // field name is T2
> P.T3  // field name is T3
> *P.T4 // field name is T4
> x, y int  // field names are x and y
> }
> 
> 
> From the encoding/json#Marshal documentation - 
> 
> Struct values encode as JSON objects. Each exported struct field
> becomes a 
> member of the object, using the field name as the object key, unless
> the 
> field is omitted for one of the reasons given below.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[C Banning]

>From the Language Specification - 

A field declared with a type but no explicit field name is called an *embedded 
field*. An embedded field must be specified as a type name T or as a 
pointer to a non-interface type name *T, and T itself may not be a pointer 
type. The unqualified type name acts as the field name.

// A struct with four embedded fields of types T1, *T2, P.T3 and *P.T4
struct {
T1// field name is T1
*T2   // field name is T2
P.T3  // field name is T3
*P.T4 // field name is T4
x, y int  // field names are x and y
}


>From the encoding/json#Marshal documentation - 

Struct values encode as JSON objects. Each exported struct field becomes a 
member of the object, using the field name as the object key, unless the 
field is omitted for one of the reasons given below.



On Monday, January 22, 2018 at 9:40:41 AM UTC-7, Axel Wagner wrote:
>
> You are right, I am wrong. I wasn't aware that the struct field would be 
> named after the alias, I assumed it would be named after the type itself. I 
> agree that this looks like a bug in the json-package and that it should 
> look at the field name itself.
>
> On Mon, Jan 22, 2018 at 4:47 PM, Josh Humphries  > wrote:
>
>> I'm not trying to suggest that the example code makes sense or is 
>> something that one *should* do.
>>
>> But it is surprising behavior that is not expected, even after reading 
>> relevant parts of the language spec and the reflect and json package docs.
>>
>> It looks like this is a bug in the json package. When it encounters an 
>> anonymous field, it looks directly at the name of the field's type, instead 
>> of the name of the field itself, to decide whether the field is exported or 
>> not:
>> https://golang.org/src/encoding/json/encode.go?s=6456:6499#L1097
>> In this case, the StructField's indicate exported names (based on the 
>> type alias names), but the field's type is simply int (which is not 
>> exported due to starting with lower-case letter).
>>
>>
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com 
>>
>> On Mon, Jan 22, 2018 at 3:12 AM, 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com > wrote:
>>
>>> On Mon, Jan 22, 2018 at 8:50 AM, dc0d >> > wrote:
>>>
 Then the main question would be why is it possible to embed type 
 aliases?

>>>
>>> Because it is possible to embed types and an alias is simply another 
>>> name for a type.
>>>
>>> For example, embedding an x/image/draw.Image 
>>>  makes 100% complete 
>>> sense: It allows your type to be used as an Image itself, while adding or 
>>> overwriting some methods. And the alias makes x/image/draw a drop-in 
>>> replacement for image/draw, so you can use your embedding type also in 
>>> functions that expect an image/draw. Also note, that even with unexported 
>>> embedded types, you are *still* promoting fields and methods 
>>> .
>>>
>>> In the end, the issue here boils down to: Aliases are a purely 
>>> compile-time feature. type Foo = Bar will *by definition* not introduce 
>>> a new actual type, but just an identifier to refer to the same type - 
>>> that's the point. Given that encoding/json works with reflection, so uses 
>>> runtime type information, it can't possibly know about your alias and will 
>>> have to assume you are embedding an int instead. And note, that embedding 
>>> an int was always possible  - 
>>> but always sorta pointless. But why explicitly disallow it? If it ain't 
>>> broke don't fix it.
>>>
>>> Why are you even using aliases in your example? It would seem that those 
>>> things either shouldn't have a name at all (and instead be field names) or 
>>> they should be actual types. Probably the former.
>>>  
>>>


 On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski 
 wrote:
>
> Given the last playground post, I'd guess that the aliased type (i.e. 
> 'int' here) is being used for visibility rather than the alias's new name.
>
> It's also a little weird to use embedded types that dont need to be 
> (there's no method promotion here because 'int' has no methods), or 
> seeing 
> aliases to primitive types. Do you need to do both of those things?
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

['Axel Wagner' via golang-nuts]

You are right, I am wrong. I wasn't aware that the struct field would be
named after the alias, I assumed it would be named after the type itself. I
agree that this looks like a bug in the json-package and that it should
look at the field name itself.

On Mon, Jan 22, 2018 at 4:47 PM, Josh Humphries 
wrote:

> I'm not trying to suggest that the example code makes sense or is
> something that one *should* do.
>
> But it is surprising behavior that is not expected, even after reading
> relevant parts of the language spec and the reflect and json package docs.
>
> It looks like this is a bug in the json package. When it encounters an
> anonymous field, it looks directly at the name of the field's type, instead
> of the name of the field itself, to decide whether the field is exported or
> not:
> https://golang.org/src/encoding/json/encode.go?s=6456:6499#L1097
> In this case, the StructField's indicate exported names (based on the type
> alias names), but the field's type is simply int (which is not exported due
> to starting with lower-case letter).
>
>
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> On Mon, Jan 22, 2018 at 3:12 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> On Mon, Jan 22, 2018 at 8:50 AM, dc0d  wrote:
>>
>>> Then the main question would be why is it possible to embed type aliases?
>>>
>>
>> Because it is possible to embed types and an alias is simply another name
>> for a type.
>>
>> For example, embedding an x/image/draw.Image
>>  makes 100% complete
>> sense: It allows your type to be used as an Image itself, while adding or
>> overwriting some methods. And the alias makes x/image/draw a drop-in
>> replacement for image/draw, so you can use your embedding type also in
>> functions that expect an image/draw. Also note, that even with unexported
>> embedded types, you are *still* promoting fields and methods
>> .
>>
>> In the end, the issue here boils down to: Aliases are a purely
>> compile-time feature. type Foo = Bar will *by definition* not introduce
>> a new actual type, but just an identifier to refer to the same type -
>> that's the point. Given that encoding/json works with reflection, so uses
>> runtime type information, it can't possibly know about your alias and will
>> have to assume you are embedding an int instead. And note, that embedding
>> an int was always possible  - but
>> always sorta pointless. But why explicitly disallow it? If it ain't broke
>> don't fix it.
>>
>> Why are you even using aliases in your example? It would seem that those
>> things either shouldn't have a name at all (and instead be field names) or
>> they should be actual types. Probably the former.
>>
>>
>>>
>>>
>>> On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski
>>> wrote:

 Given the last playground post, I'd guess that the aliased type (i.e.
 'int' here) is being used for visibility rather than the alias's new name.

 It's also a little weird to use embedded types that dont need to be
 (there's no method promotion here because 'int' has no methods), or seeing
 aliases to primitive types. Do you need to do both of those things?

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

[Josh Humphries]

I'm not trying to suggest that the example code makes sense or is something
that one *should* do.

But it is surprising behavior that is not expected, even after reading
relevant parts of the language spec and the reflect and json package docs.

It looks like this is a bug in the json package. When it encounters an
anonymous field, it looks directly at the name of the field's type, instead
of the name of the field itself, to decide whether the field is exported or
not:
https://golang.org/src/encoding/json/encode.go?s=6456:6499#L1097
In this case, the StructField's indicate exported names (based on the type
alias names), but the field's type is simply int (which is not exported due
to starting with lower-case letter).




*Josh Humphries*
jh...@bluegosling.com

On Mon, Jan 22, 2018 at 3:12 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Mon, Jan 22, 2018 at 8:50 AM, dc0d  wrote:
>
>> Then the main question would be why is it possible to embed type aliases?
>>
>
> Because it is possible to embed types and an alias is simply another name
> for a type.
>
> For example, embedding an x/image/draw.Image
>  makes 100% complete
> sense: It allows your type to be used as an Image itself, while adding or
> overwriting some methods. And the alias makes x/image/draw a drop-in
> replacement for image/draw, so you can use your embedding type also in
> functions that expect an image/draw. Also note, that even with unexported
> embedded types, you are *still* promoting fields and methods
> .
>
> In the end, the issue here boils down to: Aliases are a purely
> compile-time feature. type Foo = Bar will *by definition* not introduce a
> new actual type, but just an identifier to refer to the same type - that's
> the point. Given that encoding/json works with reflection, so uses runtime
> type information, it can't possibly know about your alias and will have to
> assume you are embedding an int instead. And note, that embedding an int was
> always possible  - but always
> sorta pointless. But why explicitly disallow it? If it ain't broke don't
> fix it.
>
> Why are you even using aliases in your example? It would seem that those
> things either shouldn't have a name at all (and instead be field names) or
> they should be actual types. Probably the former.
>
>
>>
>>
>> On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski
>> wrote:
>>>
>>> Given the last playground post, I'd guess that the aliased type (i.e.
>>> 'int' here) is being used for visibility rather than the alias's new name.
>>>
>>> It's also a little weird to use embedded types that dont need to be
>>> (there's no method promotion here because 'int' has no methods), or seeing
>>> aliases to primitive types. Do you need to do both of those things?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

['Axel Wagner' via golang-nuts]

On Mon, Jan 22, 2018 at 8:50 AM, dc0d  wrote:

> Then the main question would be why is it possible to embed type aliases?
>

Because it is possible to embed types and an alias is simply another name
for a type.

For example, embedding an x/image/draw.Image
 makes 100% complete
sense: It allows your type to be used as an Image itself, while adding or
overwriting some methods. And the alias makes x/image/draw a drop-in
replacement for image/draw, so you can use your embedding type also in
functions that expect an image/draw. Also note, that even with unexported
embedded types, you are *still* promoting fields and methods
.

In the end, the issue here boils down to: Aliases are a purely compile-time
feature. type Foo = Bar will *by definition* not introduce a new actual
type, but just an identifier to refer to the same type - that's the point.
Given that encoding/json works with reflection, so uses runtime type
information, it can't possibly know about your alias and will have to
assume you are embedding an int instead. And note, that embedding an int was
always possible  - but always sorta
pointless. But why explicitly disallow it? If it ain't broke don't fix it.

Why are you even using aliases in your example? It would seem that those
things either shouldn't have a name at all (and instead be field names) or
they should be actual types. Probably the former.


>
>
> On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski
> wrote:
>>
>> Given the last playground post, I'd guess that the aliased type (i.e.
>> 'int' here) is being used for visibility rather than the alias's new name.
>>
>> It's also a little weird to use embedded types that dont need to be
>> (there's no method promotion here because 'int' has no methods), or seeing
>> aliases to primitive types. Do you need to do both of those things?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON and Embedded Types (Aliases)

[dc0d]

Then the main question would be why is it possible to embed type aliases?

On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski 
wrote:
>
> Given the last playground post, I'd guess that the aliased type (i.e. 
> 'int' here) is being used for visibility rather than the alias's new name.
>
> It's also a little weird to use embedded types that dont need to be 
> (there's no method promotion here because 'int' has no methods), or seeing 
> aliases to primitive types. Do you need to do both of those things?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON and Embedded Types (Aliases)

[Kevin Malachowski]

Given the last playground post, I'd guess that the aliased type (i.e. 'int' 
here) is being used for visibility rather than the alias's new name.

It's also a little weird to use embedded types that dont need to be (there's no 
method promotion here because 'int' has no methods), or seeing aliases to 
primitive types. Do you need to do both of those things?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON and Embedded Types (Aliases)

[C Banning]

https://play.golang.org/p/SiWmBrUYUXF

On Saturday, January 20, 2018 at 11:16:20 PM UTC-7, dc0d wrote:
>
> Playground , output: {"Test":100}.
>
> On Sunday, January 21, 2018 at 9:42:39 AM UTC+3:30, dc0d wrote:
>>
>> Why embedded type aliases get ignored through JSON marshaling?
>>
>> For example, having:
>>
>> type Num = int
>> type Count = int
>> type Max = int
>> type Test int
>>
>>
>> type data struct {
>>  Num
>>  Count
>>  Max
>>  Test
>> }
>>
>>
>>
>> The only embedded part that gets marshaled to JSON properly, is Test.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: JSON and Embedded Types (Aliases)

[dc0d]

Playground , output: {"Test":100}.

On Sunday, January 21, 2018 at 9:42:39 AM UTC+3:30, dc0d wrote:
>
> Why embedded type aliases get ignored through JSON marshaling?
>
> For example, having:
>
> type Num = int
> type Count = int
> type Max = int
> type Test int
>
>
> type data struct {
>  Num
>  Count
>  Max
>  Test
> }
>
>
>
> The only embedded part that gets marshaled to JSON properly, is Test.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.