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 > <https://play.golang.org/p/P0gUjbf6qRD>. > > > On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian <kaveh.sh...@gmail.com > <javascript:>> 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" <j...@fullstory.com> 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 <https://www.fullstory.com/> | Atlanta, GA >>>> >>>> Software Engineer >>>> >>>> j...@fullstory.com >>>> >>>> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe <rogp...@gmail.com> 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 <jh...@bluegosling.com> >>>>> 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 >>>>> >> <dan.ko...@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...@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. >>>>> >>>> >>>> >>>> -- >> 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 <javascript:>. >> 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.
