TODO.txt

-- 2015/01/09
# support data type: interface

DOCUMENT VERY CAREFULLY HOW VALIDATION WORKS! "implicit diving into pointers". then user has validated struct ok,
  what happend when they try to type assert hmm? do [plan] and make it clear and that they need to use some other
  library to reach the data maybe or something

BLABLABLA WTF
  reasoning:
    passing interface{} value copies the data, and that needs to be avoidable.
    (for example `json.Unmarshal` needs a pointer to an interface{} as well)
  plan:
    generic function that uses reflection to reach the first non-pointer &
    non-interface value and then returns that reflection Value.
    (this function would then be used in the beginning of every validator
    workhorse)

# [MAYBE] validation functions should be more generic
reasoning AGAINST:
	it could also be reasoned to make the supplied validators fixed in a way
	that they cannot be extended, and if someone wanted more functionality,
	they'd write their own Validator.
reasoning FOR:
	_validation functions_ are exported and meant to be used from outside.
	currently each validator needs it's own type-specific validator function.
	this does not scale, because if someone wanted to do something more fancy
	with them, they cannot. for example, the following isn't currently possible:
	"to relay a path with an error from `type BooleanOpt func(bool) error`"
plan:
	to-be-figured-out.

# tests should be more generic / follow a pattern
resoning:
	it's easy to forget (as I did at first) to test for example non-nil and nil
	values of different type or other such corner cases. this applies to each
	validator that handles types and hence should be generic/follow a pattern
plan:
	maybe a function doing the "generic" tests using reflection, or a function
	taking functions for doing the "generic" tests.
	to-be-figured-out.