Hey Dan,
>> 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.
Yes, I think this is probably the discursive area that is causing a divide in
vote.
The only compromise I can think of (though not sure on its feasibility) would be
to have a flag as the last parameter that defaulted to logically AND'ing its
args
with the ability to switch the semantics to logically OR the args.
> 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
I could understand this POV if it caused a lot of changes, but the patch is
pretty simple a small. I think the potential benefits brought by this feature
is worth its weight against 10 lines of additional code in the language grammar
file.
> cheers
> Dan
Thanks for reclarifying the issues you have with this RFC.
-Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
