Skip to content
This repository has been archived by the owner on Jan 9, 2024. It is now read-only.

Validate callables #72

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Validate callables #72

wants to merge 4 commits into from

Conversation

bartfeenstra
Copy link
Owner

No description provided.

@bartfeenstra bartfeenstra changed the title First stab (and persistent stash). Validate callables Sep 19, 2017
@bartfeenstra
Copy link
Owner Author

bartfeenstra commented Sep 20, 2017

One of the problems is that many callables developers may want to use do not conform to the interfaces we'll be defining here:

  • They're built-in and use validation mechanisms other than type declarations.
  • They're PHP 5-compatible and therefore cannot use scalar or return type hints.

We can optionally whitelist callables per callable type, like registering \is_string() and siblings as valid predicates, even though their signatures may not indicate so. Manual registration should be allowed, but for built-in functions we may be able to use get_defined_functions(). It also enforces developers to use type declarations while a large portion of them prefers duck typing. Catering to that audience is not a priority (type declarations improve debugging and validation experiences and that's exactly what we're trying to do here), but it would be nice if duck typing could be supported. Maybe a global assertion validation level? Maybe consider callables valid if they may not be as strictly defined as the prototype prescribes, but cannot be confirmed as otherwise incompatible? An example of this would be to allow is_string() based on the fact it takes the correct number of arguments, and does not specify any types that would violate the prototype's contract. This deviates from interface implementation compatibility (which is what we were trying to emulate here), but would prevent MANY false negatives.

@bartfeenstra
Copy link
Owner Author

bartfeenstra commented Sep 20, 2017

The same applies to currying and partial application, as the closures they produce do not specify return values.

func_get_args() is also tricky, not because we cannot validate the number of parameters (because less than provided is always fine), but because there's no way to check the types of arguments the function obviously accepts.

I guess we have to accept any solution we come up with can tell most, but not all invalid callables are invalid, but it can never certainly say any callable is 100% valid, at the very least due to func_get_args().

@coveralls
Copy link

coveralls commented Dec 1, 2017

Coverage Status

Coverage decreased (-21.9%) to 76.203% when pulling f35b5bb on assert-callable into c4afb56 on master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-22.2%) to 77.468% when pulling 14c2a42 on assert-callable into 0b974c9 on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-22.2%) to 77.468% when pulling 14c2a42 on assert-callable into 0b974c9 on master.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants