I also couldn't help but read through the release notes of Go 1.4 last night.
I agree with Gustavo that we should avoid code generation unless absolutely necessary. I have a strong feeling that it won't be necessary given how far we have come without it. I did like the internal packages, however these are only enforced in the Go standard library with 1.4, and other packages with 1.5. Still a good idea though. Tim On 12/12/14 06:56, Gustavo Niemeyer wrote: > Thanks for the write up Katherine, and I agree these are all very nice > improvements. > > On this list, the one I find slightly less exciting is "go generate". > This is essentially a standard way to run external processing tools, > which might already be done before anyway via standard practices. For > example, the gl package in Go QML was already being generated via a > Makefile before, and it's nice that we can now give a hint about how to > re-build the generated sources, but it's a nice convenience rather than > an enabler. > > I'm also slightly worried about all the excitement that has surfaced in > the community with "go generate". Generating code is very useful and > powerful, but comes with a price (debugging, readability, etc). I'd > rather NOT generate code whenever possible. > > > > On Thu Dec 11 2014 at 2:21:20 PM Katherine Cox-Buday > <katherine.cox-bu...@canonical.com > <mailto:katherine.cox-bu...@canonical.com>> wrote: > > Hey All, > > I just got done reading through the Go v1.4 release-notes[1], and > these are some high-level thoughts about what pieces may be of > interest to Juju development. This is certainly not comprehensive, > but I thought you all might be interested. Happy release day :) > > * *go generate > *https://golang.org/doc/go1.4#gogenerate > This is *very* powerful and could reduce the number of > copy/paste snippets, or unsafe reflection code we have to write. > For those of you who are familiar with the lisps, this is > essentially macros. You write code that examines Go expressions > and does something. This code is triggered by ///go:generate > command arg/ comments in the code. As a quick example, our > StringSet type could be generated and even expanded to encompass > any type. > * *New func TestMain(m *testing.M) > *https://golang.org/pkg/testing/#MainStart > Since we use gocheck and gocheck requires you to register the > testing subsystem, this now looks like the best place to do > this. Without this, you can run into difficult to debug behavior > when filtering to certain subsets of tests, or duplication of > registration. > * *Canonical Import Paths* > https://golang.org/doc/go1.4#canonicalimports > This helps out when using the gopkg.in <http://gopkg.in> > pattern. For libraries that are specific to Juju, we may want to > specify this to help enforce the notion that we want to use > gopkg.in <http://gopkg.in> and not github.com/* > <http://github.com/*> or launchpad.net/* <http://launchpad.net/*>. > * *Internal Packages* > https://golang.org/doc/go1.4#internalpackages > Just what it sounds like. We can now hide implementation details > from importers. Probably more useful for the ancillary Juju > packages as Juju Core is probably not imported very much. > > - > Katherine > > [1] https://golang.org/doc/go1.4 > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/__mailman/listinfo/juju-dev > <https://lists.ubuntu.com/mailman/listinfo/juju-dev> > > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev