Sketch: a different take on defaulting values

As compared to #2541 

One thing I don't like about this is the round-trip tests are all broken,
with no obvious fix.  We could hybrid the approaches and make conversion
call an ApplyDefaults method, and then make tests do that too, but it's
still manual for the tests.  Or we could make Convert() take a flag for "and apply defaults" and not do defaults in fuzzing tests.  Or we can limit what sorts of things are allowed to be defaults (so that there are never default values in fuzzing).  Or we could add struct tags that say "has a default" and treat those specially during fuzzing.
Because defaults depend on which API version came in.  Believe it or not,
we can change default values across API versions.

On Mon, Nov 24, 2014 at 11:44 AM, Daniel Smith <notifications@github.com>
wrote:

> In pkg/api/v1beta1/defaults.go:
>
> > +distributed under the License is distributed on an "AS IS" BASIS,
> > +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > +See the License for the specific language governing permissions and
> > +limitations under the License.
> > +*/
> > +
> > +package v1beta1
> > +
> > +import (
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/api"
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/util"
> > +)
> > +
> > +func init() {
> > +	api.Scheme.AddDefaultingFuncs(
> > +		func(in *Volume, out *api.Volume) {
>
> Why would a defaulting function need both in and out? I think it should
> take only one value, of the destination type. Then you also only write them
> in pkg/api, not every versioned package.
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/2571/files#r20816097>
> .
>