embeding private struct in public struct

[Forud A]

Hi Gophers,

I have a public struct that embed  another internal struct with public fields like this :

type a struct {
  X int
}

type B struct {
   a
   Y int
}

in other package I can use B.X and B.Y , the problem is :
1- can not directly initialize X when I create new B like this : B{X: 1, Y: 10}, is there anyway to do this without a secound line like v.X=10 ? (this is not so important, another line of code is not a big deal)
2- the other problem (important for us :)) ) is in document for B, there is no sign of the X. I think this is some kind of bug in godoc, or something that I miss?

[Péter Szilágyi]

The first can be solved, but it's not necessarily good looking: http://play.golang.org/p/gwNupAg0GM

The second I leave to someone else :)

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

[Nate Finch]

unexported identifiers are unexported.  This is not inheritance.  X is still a field on a, not B.  B.X is just an alias for b.a.X.  The reasons for #1 and #2 are the same.  Unexported identifiers can't be accessed by external packages and thus is not documented in godoc.

[roger peppe]

On 24 March 2015 at 10:20, Nate Finch <nate....@gmail.com> wrote:
> unexported identifiers are unexported. This is not inheritance. X is still
> a field on a, not B. B.X is just an alias for b.a.X. The reasons for #1
> and #2 are the same. Unexported identifiers can't be accessed by external
> packages and thus is not documented in godoc.

I'm afraid you're wrong there. Even though the type a is not exported, its
members are still publicly available, so B.X is publicly available.

This is an outstanding bug in godoc: https://github.com/golang/go/issues/6127

There are places it's a real issue. For example in
http://godoc.org/gopkg.in/check.v1#C
the C type has a benchmark-related field, N, which is necessary in order to use
the benchmark functionality correctly, but is undocumented because of
this issue.

Forud, you have two choices - either export the embedded type
or make sure that your documentation explicitly mentions the additionally
available fields.

I'd recommend that fields like this are not part of the required
initialization of
such a struct. As you suggested, the way to do it is with an additional
assignment statement.

Aside: it's perhaps interesting to note that when using reflect,
anonymous fields do not get a non-empty PkgPath (see
http://golang.org/pkg/reflect/#StructField), indicating that they are
not truly private.

cheers,
rog.

>
> On Tuesday, March 24, 2015 at 6:09:50 AM UTC-4, Forud A wrote:
>>
>> Hi Gophers,
>>
>> I have a public struct that embed another internal struct with public
>> fields like this :
>>
>> type a struct {
>> X int
>> }
>>
>> type B struct {
>> a
>> Y int
>> }
>>
>>
>> in other package I can use B.X and B.Y , the problem is :
>> 1- can not directly initialize X when I create new B like this : B{X: 1,
>> Y: 10}, is there anyway to do this without a secound line like v.X=10 ?
>> (this is not so important, another line of code is not a big deal)
>> 2- the other problem (important for us :)) ) is in document for B, there
>> is no sign of the X. I think this is some kind of bug in godoc, or something
>> that I miss?
>

[Nate Finch]

Oh wow, thanks for the correct, Rog.  I didn't realize it really was a bug in godoc. 

[F0ruD A]

Péter :its not valid code if you are inside another package, I use this way in same package, but not in other package. the other way is to initialize this in a function in the base package.

Nate Finch : but I can access B.X outside of this package, so, the document should say that.my problem is, the template designer need to know the context inside template, and normally he lock at the documents of packages. thats why documents exists!  alias or anything you call this, should be in documents.
is there any way (without exporting the unexported struct) to cover this in documents? for now, the only way  is "Use the source luke!" and I need an alternative.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/6em4O4Up3pE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-----------------------------

http://fzero.rubi.gd

[F0ruD A]

Thank you. I search for wrong keyword in issue :) so its known bug.

The problem is not initializing the struct, as I said in my other email, the problem is the non-gopher team member :)

Thank you all.

--

-----------------------------

http://fzero.rubi.gd