There was small typo in my previous link to object comparison: new one is https://3v4l.org/tMokY
2016-12-27 14:33 GMT+03:00 Alexander Lisachenko <lisachenko...@gmail.com>: > Hi, internals! > > I want to propose to deprecate one more weird feature of PHP called > "comparison of different types" http://php.net/manual/en/ > language.operators.comparison.php#language.operators.comparison.types. > Here you can check one simple example https://3v4l.org/kCOAf to see why > it should be deprecated. > > It would be nice to deprecate all comparison operators between different > types and throw an exception later in future version of PHP. > > Operators that should be allowed for comparison of different types are the > following: ==, !=, ===, !==, <>. > Operators to deprecate for comparison of different types are the > following: >, <, >=, <=, <=> > > I also think about deprecation of string/object/array comparison with > operators like greater/less, because it's hard to understand results for > '1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison > https://3v4l.org/5At1l > > Thanks! > > 2016-12-27 9:52 GMT+03:00 Stanislav Malyshev <smalys...@gmail.com>: > >> Hi! >> >> >> https://wiki.php.net/rfc/deprecations_php_7_2 >> >> Reading through the list, I find several categories: >> >> Completely ok: >> >> (unset) - don't see any sane use case anyway >> gmp_random >> >> Can cause breakage but it's ok: >> >> $php_errormsg >> __autoload >> mbstring.func_overload >> parse_str() - people can use it in functions, it doesn't have to be >> globals. But it's cleaner with second arg. >> $errcontext >> >> Don't see a reason to remove: >> >> (binary) cast and b"" - yes, they are not currently doing anything. But >> they don't also hurt anything. >> >> High breakage potential: >> >> each() - I've seen a lot of code using each. Yes, it's not the best way. >> A lot of people write code not in absolutely best way but in a way they >> like to. Argument about list() proposed in RFC makes little sense to me >> - since problem is with list() and not each() why each() should be >> deprecated because of it? And I certainly object its removal. >> >> create_function() - yes, there are closures now. But there's a lot of >> code created when there were none, and that code works, and there's no >> reason to break it. I'd probably be OK with deprecation warning but not >> with removal. >> >> Special case: >> assert() - if the string arg is a security issue, deprecating it >> achieves nothing. So I'm not sure I understand the argument for >> deprecation - if string assert is a problem we probably should make >> assert() construct instead check if assert is used in eval form, not by >> argument count? >> >> -- >> Stas Malyshev >> smalys...@gmail.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >
