On 2011-06-06, Stas Malyshev <[email protected]> wrote:
> > Like I mentioned in the other thread (which I probably should had
> > repeated here), a lot of libs/frameworks are using the 'Closure'
> > typehint for callbacks.
>
> Well, they are wrong (unless they mean to use only closures and not
> callbacks). But that's no reason to do wrong thing in the language
> too.
>
> > The problem with that is a function name as a string and
> > array("classname", "functionname") are considered is_callable(). To
> > get through the intentions of the Closure hint, I would have to wrap
> > the actual callback in a closure - which doesn't make any sense.
>
> "callable" is not actually even a type. If we make it a language
> construct, then why 'authenticated DB connection', 'name of readable
> file', 'valid stream URL', 'validated XML', 'string in UTF-8 no
> longer
> than 255 characters' or 'balanced binary tree' is not a language
> construct? I don't think we need to put every data check into the
> language, especially that it actually makes it worse - you can
> gracefully handle user-space check, but not a strict typing error.
The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:
public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}
The typehint makes this simpler:
public function addCallback(callback $callback)
which allows us to rely on PHP's native error handling. I, for one,
would love to see this.
--
Matthew Weier O'Phinney
Project Lead | [email protected]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc