[Canonical-tech] Handling active dependencies in Go

Gustavo Niemeyer gustavo at niemeyer.net
Tue Dec 18 13:08:51 UTC 2012


That's side tracking the topic of the thread, but since it was brought up
with the thread itself, here we go.

The convention is already clear: most places return pointers, both in juju
and in the Go stdlib itself. Some types, though, benefit from being used as
values due to their nature. That's the case of time.Time, for example.

Both are fine approaches, and as long as you're thinking about what's the
behavior you expect over usage of the type in terms of copying, mutability,
memory usage, lifetime of the value, etc, you can pick either and run with
it.

The case brought up was an inconsistent use where there were two private
functions side by side returning type T, one as pointer and one as value.
This indicates that there wasn't real consideration of which way to go, and
was brought up in the review for fixing. It was literally a 30 seconds fix,
but has proven quite controversial somehow.
 On Dec 18, 2012 9:53 AM, "Free Ekanayaka" <free.ekanayaka at canonical.com>
wrote:

> Hi John,
>
> On Mon, Dec 17, 2012 at 11:03 AM, John Arbash Meinel
> <john.meinel at canonical.com> wrote:
>
> >    Eg, we recently had a discussion about whether functions should
> >    return structs or pointers to structs. Once that is settled, it
> >    would be good to update most APIs to be consistent with that.
>
> Unrelated to the topic of this thread, but please could you give
> pointers to that discussion? I'd be interested in reading it, and
> check the outcome too.
>
> Thanks,
>
> Free
>
> _______________________________________________
> Mailing list: https://launchpad.net/~canonical-tech
> Post to     : canonical-tech at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~canonical-tech
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20121218/ca9ab068/attachment-0001.html>


More information about the Juju-dev mailing list