lots of small nested packages

391 views
Skip to first unread message

Joel Reymont

unread,
Aug 30, 2012, 1:37:55 PM8/30/12
to golang-nuts
What is the party line on small nested packages?

Think a number of them like signal, all nested under os.

In my case, I'm thinking of making small individual packages for
various financial instruments, all under my trade package, e.g.

github.com/wagerlabs/go.trade/stock
github.com/wagerlabs/go.trade/option
github.com/wagerlabs/go.trade/future

etc.

Among other things, this would allow me to have functions like
stock.Make instead of trade.NewStock, something that I much prefer
aesthetically.

Thanks, Joel

Rob Pike

unread,
Aug 30, 2012, 2:12:55 PM8/30/12
to Joel Reymont, golang-nuts
It's too general a question for a specific answer, but it sounds like
a fine approach to try.

-rob

Joel Reymont

unread,
Aug 30, 2012, 2:19:10 PM8/30/12
to golang-nuts
On Aug 30, 7:13 pm, Rob Pike <r...@golang.org> wrote:
> It's too general a question for a specific answer, but it sounds like
> a fine approach to try.

Thanks Rob!

A related question then...

Is there a way to have 'go build' rebuild -all- nested packages from
the top of the tree?

Rob Pike

unread,
Aug 30, 2012, 2:20:17 PM8/30/12
to Joel Reymont, golang-nuts
cd wherever
go build ./...

Rob Pike

unread,
Aug 30, 2012, 2:20:43 PM8/30/12
to Joel Reymont, golang-nuts
You probably want

go install ./...

though.

-rob

Steven Degutis

unread,
Aug 30, 2012, 2:25:31 PM8/30/12
to golan...@googlegroups.com
I like the idea. One note though, I think the idiom is stock.New() instead of stock.Make()

-Steven

Joel Reymont

unread,
Aug 30, 2012, 4:20:35 PM8/30/12
to Rob Pike, golang-nuts
Rob,

On Thu, Aug 30, 2012 at 7:12 PM, Rob Pike <r...@golang.org> wrote:
> It's too general a question for a specific answer, but it sounds like
> a fine approach to try.

Please take a look here:

https://github.com/wagerlabs/go.trade

I restructured everything into small packages and I like it, personally.

--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

Kyle Lemons

unread,
Aug 30, 2012, 4:48:49 PM8/30/12
to Joel Reymont, golang-nuts
Be wary of making packages *too* small.  My probably unhelpful suggestion is to make a package only as big as it needs to be to be to accomplish a task. Often you can tell you may be making them too small if you find yourself needing unexported state from another package or you find you are introducing a circular dependency.

tomwilde

unread,
Aug 31, 2012, 9:58:26 AM8/31/12
to golan...@googlegroups.com
Because the different asset types (I imagine) share a considerable part of their behavior, I would put them into a single package.
Separating them in different packages may give you trouble in the future and force you to export currently unexported methods or types in order not to repeat code in the other asset type packages.
It's best to keep closely related concept bundled together.
Reply all
Reply to author
Forward
0 new messages