ValidatorMixin isn't very good

[Julian]

It couples validators to the instance's __dict__ and so therefore requires extensibility to happen through inheritance.

E.g., if Foo is an IValidator that uses ValidatorMixin and you want to add your own totally cool validators that extend Foo's validators, you need to inherit.

Instead, it should be possible to wrap a validator, and / or to separate ValidatorMixin's implementation of all the convenience method implementations (validate, is_valid, etc.) from its implementation of iter_errors.

Modifying IValidator to specify a dict where validators live might be appropriate.

E.g. specify a validators attribute that should map validators to validator functions ({"type" : validate_type}) that will be called with an IValidator and all the stuff it gets called with now. This would solve a small side problem which is that validators currently sorta have to be valid identifiers.

Then ValidatorMixin.iter_errors would delegate to ValidatorMixin.validator_for (see e.g. dfcd6e8 which has been temporarily reverted), for which the default implementation would just be return self.validators.get(validator)

The docs should be updated to specifically discourage any inheritance anymore.

@gazpachoking thoughts?

[gazpachoking]

This sounds pretty good to me. I'm not certain subclassing is really that much of a problem, but I definitely like the fix for validators like $ref.

[Julian]

So, still playing with this in my head.

Just so I record this on paper for future reference, though I'll probably implement it tomorrow or so, the new API for making validators will probably look lke

Draft4Validator = make_validator(
    name="draft4"
    meta_schema=json.load(draft4_schema),
    validator_fns={"type" : _validate_type, "$ref" : _validate_ref, ...},
)

[Julian]

Fixed in 0fe509c.