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
<[email protected]> 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
> [email protected]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
