On Wed, Feb 11, 2015 at 7:51 PM, William Reade william.re...@canonical.com
wrote:
On Tue, Feb 10, 2015 at 11:35 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Not sure I follow what you're saying about in terms of the storage
types,
so
I'll describe how it is at the moment.
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
-
So, I think you *do* need conversion code specific to state -- the
methods exported from state should be in terms of the storage types,
because they're the language we've chosen to model storage, so there
needs to be conversion code in state (or possibly in an internal
package -- but either way
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
On Tue, Feb 10, 2015 at 5:44 PM, William Reade william.re...@canonical.com
wrote:
So, I think you *do* need conversion code specific to state -- the
methods exported from state should be in terms of the storage types,
because they're the language we've chosen to model storage, so there
needs
