On 2011-06-06, Stas Malyshev <smalys...@sugarcrm.com> 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 | matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
