[RFC][Discussion] In Operator View as Markdown

2015-02-20 19:48 GMT+01:00 Markus Fischer markus@fischer.name:

Hi internals,

It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.

That is an understatement:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr.php#L443

I don't think changing the language in a way that breaks Doctrine
would be feasible.

I second this. I didn't immediately reply when I read this restriction
regarding methods but it should have been obvious.

IMHO this is an absolute no-go; and the contex_sensitive_lexer sounds
reasonable but has it's own problematic areas.

• Markus

--

It would clearly break Doctrine in its current state if we don't get
in that context sensitive
parser, but I want to point out, that it would still be fixable by
using a magic method for that,
like it's pointed out here:
https://twitter.com/danielgsims/status/568823804849496064

Of course that would be rather hacky.

Regards, Niklas

2015-02-21 1:07 GMT+01:00 Pádraic Brady padraic.brady@gmail.com:

On 20 February 2015 at 23:38, Larry Garfield larry@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

--

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