> Am 19.09.2013 um 11:10 schrieb "Leigh" :
>
> On 19 September 2013 03:20, William Bartlett
> 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 certainly expect is_three
On 19 September 2013 03:20, William Bartlett
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 certainly expect is_three to return false, but I would also expect
> $i to contain thr
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 wei
Am 18.09.2013 um 21:57 schrieb "Leigh" :
> On 18 September 2013 18:50, Bob Weinand 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
On 18 September 2013 18:50, Bob Weinand 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 one
Feels lik
Am 18.9.2013 um 18:09 schrieb Leigh :
> On 18 September 2013 14:50, Sean Coates 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 p
On 18 September 2013 14:50, Sean Coates 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 short-circuiting
> w
2013/9/18 Sean Coates :
>> 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
2013/9/18 Chris London :
> 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 proposed by Leigh
> 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 Ru
2013/9/18 Sean Coates :
>> 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 `&&`:
>
>
> fun
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 wrote:
> > i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b)
> 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 `&&`:
13 matches
Mail list logo
