Things which may be of interest in Go v1.4

[Gustavo Niemeyer]

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> 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 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 and not github.com/* or 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
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141211/5bec161b/attachment.html>