ksonnet seems to penalize breaking up large objects about ksonnet-lib HOT 4 CLOSED

You're right, we meant to add this, but didn't get around to it. I could have sworn there was an issue open to do it, but I guess not.

from ksonnet-lib.

So I think there are a few options here.

1. Add a "transformer" to *Type. For example, metadataType.toMixin(meta):: __podTemplateMixin({metadata+: meta}) would take a metadata object, and lift it into a mixin that sets the metadata property in a pod template (as an example). The downside is that metadataType exists in many places, and is supposed to be identical in all places, but this would make it context-specific. This will also be a problem if we transition away from the "embedding *Type where it exists -- we'll just end up here with the same problem again.
2. Add a "setter" to the mixin object itself. For example, mixin.metadata.setProperty(meta):: {metadata+: metadata}. There are two downsides to this approach. The first is that everything other property in the mixin.* namespace is set with a method that has the name of the property. For example, mixin.metadata.labels sets the labels property.
   The second it's a semantic mismatch for how top-level API objects set properties. For example, we would expect something like deployment.foo to set the foo property, so why should we set the metadata property with something like deployment.mixin.metadata.setProperty?
3. Have a "setter" next to each mixin. So for example, we have metadataType, metadata, and setMetadata.

from ksonnet-lib.

So I'm thinking we probably want to go with (2). I actually think it does make sense after all.

My big complaint before was that it's weird to use deployment.foo to set the foo property, but the deployment.mixin.metadata.setProperty function to set metadata. There are two things that convinced me that this is not so weird.

First, a function like deployment.mixin.metadata.annotations calls something semantically identical to setProperty under the covers anyway, the difference is that instead of mixing in a property, setProperty mixes in an instance of v1.ObjectMeta. If we call it something like deployment.mixin.metadata.mixinInstance, then I think this might be clearer.

Second, the fact that this is semantically similar is underscored when we consider deeper-nested types. For eample, something like deployment.mixin.metadata.initializers.mixinInstance makes sense, because we're mixing an instance of the initializer into a deployment object.

from ksonnet-lib.

Another thing to consider is: do we want we want to distinguish between setters and mixins? A function like container.ports will append to a current list of ports, but completely replacing the array is a bit more manual, because you need to actually write an object literal like {ports: []}.

As it relates to this discussion, we now have 2 questions:

1. Should the semantics of mixinInstance set the property, or merge the instance with super?
2. Should this distinction be made for other methods, too?

from ksonnet-lib.