On 2011-06-06, Pierre Joye <pierre....@gmail.com> wrote:
> --0016e6de0029ddc06f04a5129914
> Content-Type: text/plain; charset=ISO-8859-1
>
> How is this argument different than the one in favor of type hinting (or
> whatever was what ended in trunk)?
I was simply voicing my support for Hannes' patch, and trying to clarify
my understanding of it for Stas.
If you're comparing it to the scalar typehinting patch, I think it's a
far cry from that -- this is about providing a unified typehint for
functionality represented over multiple constructs in PHP, in order to
reduce code in applications. If it offers no BC issues, and allows
developers to simplify code and remove boilerplate (which can easily
introduce new errors on each iteration), then why wouldn't it be a good
idea?
> On 7 Jun 2011 00:16, "Matthew Weier O'Phinney" <weierophin...@php.net>
> wrote:
> > 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
> >
>
> --0016e6de0029ddc06f04a5129914--
--
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
