On not copy-pasting state and params struct conversions

[roger peppe]

I think that the danger here is one of backwards incompatibility,
and that's a danger that's possible to alleviate with some tooling
support.

Writing tons of boilerplate code to manually convert between types at different
levels has always seemed like a poor use of developer resources to
me (and opens up more possibility for conversion errors).

When things *do* change in a backwardly incompatible way, then
of course conversion code would need to be written, but if
there is a tool that can automatically test that things remain compatible,
this could be only a small percentage of what is being done up
front now.

  cheers,
    rog.


On 10 February 2015 at 09:07, Andrew Wilkins
<andrew.wilkins at canonical.com> wrote:
> Hi all,
>
> Anastasia raised an issue in http://reviews.vapour.ws/r/885/ about how to
> cut down on struct conversions between params, state, and domain packages.
> In this case we're talking about storage. The following API server facades
> currently participate in storage:
>    - client
>    - storage
>    - provisioner
>    - diskmanager (to be renamed, this lists block devices on machines)
>    - diskformatter
>    - storageworker (to be renamed, this is the dynamic storage provisioner)
>
> Each facade have some overlap in dealing with storage entities, e.g. the
> diskformatter and diskmanager each need to deal with block devices. This
> leads to much duplication of struct copying/conversion code when toing and
> froing between state and clients.
>
> I don't want to go adding conversion code to the params, state or storage
> packages, as they really shouldn't have dependencies on each other. Does
> anyone have a good idea about where to put this common functionality? Maybe
> "api/common/storage", "apiserver/common/storage"? Does not appeal, but I
> can't think of a better option.
>
> Cheers,
> Andrew
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>