Am 19.09.2013 um 11:10 schrieb Leigh lei...@gmail.com:
On 19 September 2013 03:20, William Bartlett
william.a.bartl...@gmail.com wrote:
I would argue that LTR support is also inconsistent / not desired.
If I wrote:
$i = 0;
is_three($i = $i + 1, $i = $i + 1, $i = $i + 1);
I would
On Wednesday, September 18, 2013 at 12:53 PM, Leigh wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
On Wed, Sep 18, 2013 at 7:50 AM, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as
2013/9/18 Sean Coates s...@seancoates.com:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they appeared in the OP.
S
--
PHP Internals - PHP
2013/9/18 Chris London m...@chrislondon.co:
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
isset() already operates that way, keeping is_ and implementing it
as originally
2013/9/18 Sean Coates s...@seancoates.com:
Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the
Am 18.9.2013 um 18:09 schrieb Leigh lei...@gmail.com:
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()`
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
and being able to execute the ZEND_SEND_VAL opcodes one by
Am 18.09.2013 um 21:57 schrieb Leigh lei...@gmail.com:
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
I would argue that LTR support is also inconsistent / not desired.
If I wrote:
$i = 0;
is_three($i = $i + 1, $i = $i + 1, $i = $i + 1);
I would certainly expect is_three to return false, but I would also expect
$i to contain three. php doesn't normally evaluate arguments lazily, it
would be
13 matches
Mail list logo
