what's iValueObject for during the validation step?

[igorsantos07]

I was trying to get a smarter type class (so I can use it to do sanitization as well), and stumbled upon iValueObject, which seems to... short-circuit param validation? It seems that, if I supply an object implementing that interface as a param type, it will not validate any of the types declared on it, is this correct?

I see no documentation whatsoever on that behavior, and that interface is only very briefly mentioned in V4 docs (in the V3 subdomain? confusing) about return object documentation.

What's the idea? Should iValueObject implement its own in-house validation instead? It would be very nice if we could integrate more robust objects into the call params. Specifically, I was trying to turn my types into Laravel Collections, but it doesn't really work since they store their values inside a private property, while Restler depends on publicly named props to identify the types. It would be easy to allow extensibility there; either the Validator part that sets a value could be extensible, or if it checked for a custom setter instead of just $instance->{$key}. If this sounds interesting, I can provide a PR for the latter (but this is actually a different topic).

[Arul-]

iValueObject should not do short circuit validation. Can you provide an example?

Restler 3 had two versions RC5 and RC6 both maintained at the same time which lead to much confusion

So RC5 became Restler 4, RC6 became Restler 5