2015-02-21 1:45 GMT+01:00 Niklas Keller <m...@kelunik.com>:
> 2015-02-21 1:07 GMT+01:00 Pádraic Brady <padraic.br...@gmail.com>:
>> On 20 February 2015 at 23:38, Larry Garfield <la...@garfieldtech.com>
>> wrote:
>>> While I love the idea, strict type comparison for in would, in essence,
>>> be a
>>> toe-dip into the scalar strict typing world (see other thread) that would
>>> be
>>> very confusing. Consider:
>>>
>>> if (3 in $_GET['filters']) { ... }
>>>
>>> That would always be false, because $_GET is always strings. To make
>>> that
>>> work I'd need to first cast all of the elements in that array to ints...
>>> which I'm not actually sure how to do cleanly.
>>
>> You need casting anyway if comparing raw GET/POST directly to any
>> integer as a decision point on whether to use the raw value, i.e. it's
>> unvalidated otherwise and could have been "1234<script>[...]".
>>
>> Yes, I'm abusing your intentionally very simple example. There are
>> other cases away from user input where looser comparisons wouldn't
>> have the same potential issues with non-permanent type juggling. I
>> would be a huge fan of having it be strict since the above, while
>> clearly a simple example, has been problematic in the past for
>> validation routines and, as a security guy, I'm obsessed with that ;).
>> Also, on toe-dipping into strict typing, I think your opinion may be
>> slightly overweight towards that topic given recent RFC history - we
>> already have === as our toe in the water.
>>
>>> I'd much rather we tighten up the rules around implicit casts generally,
>>> as
>>> discussed elsewhere, and then allow those "loose but not as loose as we
>>> have
>>> now" rules here.
>>
>> I could work with that perhaps. RFCs of this type are in a bit of a
>> bind while we wait for scalar typehints/potential casting rules to be
>> finalized in some form. It also appears unlikely that "in" as the
>> operator name will pass muster if the context sensitive lexer RFC does
>> not pass, i.e. would break uses of in() as a method name.
>>
>> Niklas, any chance you have considered a Plan B for the operator
>> naming? Mostly curious if these is already some alternative outside of
>> the field of langs I'm familiar with that might be acceptable.
>>
>> Paddy
>>
>> --
>> Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>> if (3 in $_GET['filters']) { ... }
>> That would always be false, because $_GET is always strings. To make that
>> work I'd need to first cast all of the elements in that array to ints...
>> which I'm not actually sure how to do cleanly.
>
>
> You could easily cast the left operand to a string instead.
>
>> I'd much rather we tighten up the rules around implicit casts generally,
>> as discussed elsewhere, and then allow those "loose but not as loose as we
>> have now" rules here.
>
>
> Maybe I'd be OK with that then, but not in the state we currently have. I
> think a change here would be too rushed and would therefore have to wait
> until PHP 8.
>
>> Niklas, any chance you have considered a Plan B for the operator
>> naming? Mostly curious if these is already some alternative outside of
>> the field of langs I'm familiar with that might be acceptable.
>
> Not really. It could be named `contains`, but that would create the same
> problems.
>
>> It also appears unlikely that "in" as the
>> operator name will pass muster if the context sensitive lexer RFC does
>> not pass, i.e. would break uses of in() as a method name.
>
>
> You're totally right. It's already the second RFC on that topic
> (https://wiki.php.net/rfc/keywords_as_identifiers is the other one I know).
> If context sensitive lexer doesn't parse, "in" may have to wait until PHP 8,
> which may have another RFC here.
>
> Regards, Niklas
I've updated the RFC to v0.4. I removed support for using arrays to
check for multiple values.
Additionally, it's implemented now if somebody wants to test it.
Regards, Niklas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
