Move FieldValidator Validate() methods to be be on a pointer value

[smyrman]

We use quite some documentation-real estate to explain that schema.FeildValidators should be set using pointers so that any (potential) schema.Compiler interface (maybe renamed after #100 ) can be detected and called. THere is also code catching this mis-usage and giving a runtime error.

However, it's generally better to fail faster, and it would be pretty easy to make this a compile-time error by moving the Validate method for most FieldValidator implementations to be on a pointer value:

/ String validates string based values
type String struct {
	...
}

// Compile compiles and validate regexp if any.
func (v *String) Compile() (err error) {
	...
}

// Validate validates and normalize string based value.
func (v *String) Validate(value interface{}) (interface{}, error) {
	...
}

This also means that the run-time checks can be removed!

PS! Some types, such as maps and slices, do not require neither Compiler nor Validate to be on a pointer value due to how these types work.

[smyrman]

@rs: Created a new label type for this issue. Hope that's OK.

[rs]

np, what should we use it for?

[rs]

Good idea btw. We might want to keep the check to make sure custom types are use properly even if their methodes aren’t on pointers. Does it make sense?

[smyrman]

We might want to keep the check to make sure custom types are use properly even if their methodes aren’t on pointers. Does it make sense?

Depends if we can make the tests right. Sometimes It's not thecnically necessary to use a pointer type, such as map and slice types. When there is no Compile, it's also technically no reason to make the field a pointer.

np, what should we use it for?

My thinking was to label issues that are not bugs, but could help with the stability of projects using rest-layer.

E.g.: earlier errors, safer and more robust implementations off existing features.

[smyrman]

I want to close this issue in favor of #194.