serializing to json

William Reade william.reade at canonical.com
Wed Apr 1 10:55:29 UTC 2015


On Tue, Mar 31, 2015 at 8:22 PM, Nate Finch <nate.finch at canonical.com>
wrote:
>
> Struct tags that are the same as the name of field are never needed:
>
> type SomeResult struct {
> Error *Error                    `json:"Error"`
> Somethings []Something `json:"Somethings"`
> }
>
> The above is totally unnecessary... those fields will already serialize
> into "Error" and "Somethings".  There's a bunch of this in the
> apiserver/params package... you don't need it, so don't do it.   It just
> causes confusion, because it looks like you're changing the name from the
> default, even though you're not.
>

Tim's pretty much covered this already, but I wanted to note the other big
problem with the params package: that it pulls in types from elsewhere, and
those types are a *massive* liability. For data that goes over the wire,
and data that goes into a database, please *always* be *local* and
*explicit* about what you're storing. As far as I'm concerned:

1) putting a *charm.Meta (or equivalent) direct into a database (or sending
it over the wire) is completely unjustifiable, because you're explicitly
dropping control of what you're storing/sending: some other guy can make a
perfectly reasonable change to a completely unrelated package and break
your wire format. This is a Very Bad Thing, where explicitly copying
structures at layer boundaries is merely Somewhat Tedious.

2) failing to use serialization annotations is essentially the same
mistake, because it makes it way too easy for a well-meaning programmer to
change a field name and again, whoops, break the wire format. Changing
field names is normal and good -- code evolves, abstractions change
(hopefully for the better) -- and implicit serialisation has chilling
effects there and leads to paranoid code fossilisation. (Or, worse, it
doesn't, and we just put up with a constant risk of arbitrary subtle
breakage.)

Cheers
William



>
> -Nate
>
> --
> 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/20150401/ee020dc8/attachment.html>


More information about the Juju-dev mailing list