On Tue, Oct 23, 2012 at 10:30 +0200, Iustin Pop <[email protected]> wrote: > > The resulting combination, NoDefault + TMaybeString, is that the field > > can be None, but even in that case it must be explicitly specified > > (i.e., it must be present in the serialization even if as null). The > > CLI, for example, solves this by using "cluster" as the value for name > > in the case of `gnt-cluster add-tags`, though it could have as well used > > None (I may send a patch for that, actually).
> TBH, it sends "cluster" in order to have a clear type. But maybe this is > the wrong approach. Given that the expected type is TMaybeString, and that the received string for kind == "custer" is not checked/used at all and could be any value, then my expectation was that a more correct value to send would be None, that's all. > The problem stems from the fact that the (kind, name) is in reality a > single type, but we can't express it as such at json level nicely: > data What = Cluster > | Node String > | Instance String > | Group String > … > I think that NoDefault + MaybeString is the correct type then, even if a > bit strange. Ack. > > (2) Define the field as required, forcing the programmer to always > > specify a value, even if it's just a dummy one. > > (4) Have an additional flag in the definition of Field that says if it > > should always be included in the serialization, even if the value > > is Nothing. > I'm tempted for (2), but (2) is not clean, since the dummy value is very > ugly. > (4) seems easily doable, and I can send a patch soon if we agree on > that… (4) sounds good to me, and I'd appreciate the patch greatly. (I think I should be able to review it.) Thanks, -- Dato Simó | [email protected] Corp Fleet Management / Ganeti SRE (Dublin)
