Re: [RFC] Strict operators directive

From: Date: Wed, 26 Jun 2019 12:47:21 +0000
Subject: Re: [RFC] Strict operators directive
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-106076@lists.php.net to get a copy of this message
On Wed, Jun 26, 2019 at 1:18 PM Alain D D Williams <addw@phcomp.co.uk> wrote: > On Wed, Jun 26, 2019 at 12:00:18PM +0100, Rowan Collins wrote: > > > Perl is a notable contrast: the types of operands are deduced based on > the > > operator, but there are different operators to force them to different > > types. So 23 < 4 and "23" > > < "4" are both numeric comparisons, so > return > > false; but 23 lt 4 and "23" lt > > "4" do string comparisons, and return > > true. That way the user's intent is clear, but you don't have to manually > > cast values or remember how different combinations will be interpreted. > > IMHO the Perl way is better: the different operators mean that I will get > what I > want, I don't need to worry about an accidental type juggle; it is also > (presumably) faster as the run time does not need to: look at a string, > decide > if it could be a number and maybe change what it does. > > The big problem is backwards compatibility, so new operators would be > needed: > > string compare: lt, gt, etc, not much of a problem > > numeric compare: #< #> would be nice were it not that # means comment. > > > Note that using a directive means there is no inherit backward compatibility issue. We're talking about copy/pasted code sniplets only. Solving the issues presented, maintaining BC, without the use of a directive would require the addition of multiple type-specific operators. String compare, numeric compare, array compare, etc, etc. PHP code would become unrecognizable. I'm not a fan of that alternative. Arnold

« previous php.internals (#106076) next »