Things which may be of interest in Go v1.4

[Tim Penhey]

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-buday at canonical.com
> <mailto:katherine.cox-buday at 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 at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/juju-dev
>     <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> 
> 
>