On 12 March 2015 at 09:58, Thomas Punt <tp...@hotmail.co.uk> wrote: > Hey PHP Internals, > I'm not entirely sure why > people are against it - and no one seems to want to debate it either.
I think these were covered in the discussion phase, but I will reiterate the reasons I voted against it for clarity. > The falsy semantics of empty() means that inlining its behaviour to exactly > match > isset() isn't logical. The problem isn't so much that the behaviour doesn't match some other pattern in PHP; the problem is that the function doesn't do what its name says it does. "if any arguments passed into empty() are considered falsy, then true will be returned" i.e. it doesn't check whether the arguments are 'empty', it's checking whether they are 'all set and not falsy'. Having a function do something different to what it's name suggests will lead to it being used incorrectly a lot of the time. The other reason I voted no, is that I just don't think this adds enough to the language to be implemented in core. For at least two of the examples in the RFC the desired functionality could be implemented in userland. The size of the PHP core codebase is already unwieldy. I think any suggested addition needs to have a clear advantage over being implemented in userland cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
