Initilising a struct defined in a different file

1,899 views
Skip to first unread message

Rylan Halteman

unread,
Jan 14, 2014, 10:18:43 AM1/14/14
to golan...@googlegroups.com
I'm trying to synchronise two go routines using a pattern similar to what's found here: stateful-goroutines, but I'm having issues initialising my structure.

I have a structure:

type ClientStruct struct {
resp chan int64
}

but I get a compiler error when I try to initialise it: 

client := &lib.ClientStruct {
resp: make(chan int64),
}

Error:
unknown lib.ClientStruct field 'resp' in struct literal

The problem seems to be that the ClientStruct is declared in a different file and package then where I initialise it, since when I move the structure over to the same file it works fine.  Using lib.ClientStruct.resp, or ClientStruct.resp gives an invalid field name error.

Is there any way to initialise & use a data structure that is defined in another file or package?

Thanks

Volker Dobler

unread,
Jan 14, 2014, 10:24:07 AM1/14/14
to golan...@googlegroups.com
Am Dienstag, 14. Januar 2014 16:18:43 UTC+1 schrieb Rylan Halteman:
I'm trying to synchronise two go routines using a pattern similar to what's found here: stateful-goroutines, but I'm having issues initialising my structure.

I have a structure:

type ClientStruct struct {
resp chan int64
}
[...]
Is there any way to initialise & use a data structure that is defined in another file or package?

You must either a) export resp by capitalizing it to Resp
or b) provide some kind of (again exported) initializing
function like func NewClientStruct(chan int64) ClientStruct .

V.

Robert Straw

unread,
Jan 14, 2014, 10:27:39 AM1/14/14
to golan...@googlegroups.com
If you want `resp` to be visible from another package you need to export the identifier. This is done by naming it with an upper case letter.
(See: http://golang.org/ref/spec#Exported_identifiers)

Otherwise if you don't want to export `resp` outside the package you could define getter and setters w/ your struct as a receiver. 

Rylan Halteman

unread,
Jan 14, 2014, 10:31:27 AM1/14/14
to golan...@googlegroups.com
Awesome!  Thanks for the responses.

Konstantin Khomoutov

unread,
Jan 14, 2014, 10:34:40 AM1/14/14
to Rylan Halteman, golan...@googlegroups.com
On Tue, 14 Jan 2014 07:18:43 -0800 (PST)
Rylan Halteman <rylan.h...@gmail.com> wrote:

> I have a structure:
>
> type ClientStruct struct {
> resp chan int64
> }
>
> but I get a compiler error when I try to initialise it:
>
> client := &lib.ClientStruct {
> resp: make(chan int64),
> }
>
> Error:
> unknown lib.ClientStruct field 'resp' in struct literal
>
> The problem seems to be that the ClientStruct is declared in a
> different file and package then where I initialise it, since when I
> move the structure over to the same file it works fine. Using
> lib.ClientStruct.resp, or ClientStruct.resp gives an invalid field
> name error.

Sure: according to the simple visibility rules implemented in Go,
only names starting with an uppercase letters are "exported" -- visible
in other packages (this does not apply to other files in the same
package). This is true not only for top-level functions and types but
also for struct members.

> Is there any way to initialise & use a data structure that is defined
> in another file or package?

There might be two solutions:

* Make the field named "Resp", not "resp" if you're okay with
any user of your package will be able to access this field directly.

* Provide a "constructor function" for your type which will return
a new properly initialized instance of it, like this:

func NewClientStruct(resp chan int64) &ClientStruct {
return &ClientStruct{resp: resp}
}

and then make the users of your package call this function:

client := lib.NewClientStruct(make(chan int64))

Jesse McNelis

unread,
Jan 14, 2014, 6:53:18 PM1/14/14
to Rylan Halteman, golang-nuts
On Wed, Jan 15, 2014 at 2:18 AM, Rylan Halteman <rylan.h...@gmail.com> wrote:
Is there any way to initialise & use a data structure that is defined in another file or package?

If it's just in another file then as long as that file is in the same package then it's no different than using it in the file it's defined in.


Reply all
Reply to author
Forward
0 new messages