5 ms·
Thanks for sharing this. It's good to remember that even relatively pragmatic languages like PHP often deprecate syntax features simply because they're "inferio
by phendrenad2 5y ago
Thanks for sharing this. It's good to remember that even relatively pragmatic languages like PHP often deprecate syntax features simply because they're "inferior" to another syntax feature.
- dvdkon 5y agoPHP has a strange identity problem. For a language that most would agree is used due to past popularity, it has a lot of breaking changes. But while syntax gets deprecated and function signatures changed, the stdlib is still a mess. The original randomly long functions are still there with no replacement in sight. To make my point, there's still no reasonable int parsing function! I'm not against change, but PHP devs should decide if they want to make code maintenance easier, or make PHP an actually good language. Right now, it's in a weird in-between state. I'm not a fan of coming across old PHP code and having to make a bunch of small changes to port it to supported PHP.
- baisq 5y ago>there's still no reasonable int parsing function What's wrong with (int)$val ?
- dvdkon 5y agoThere's no error handling, (int)"x" === 0.
- RedShift1 5y agoYou should use the filter functions for that
- Y-bar 5y agoWhy should that be an error? First we are explicitly forcing a string to an integer and then comparing it with type sensitivity to another integer.
- dvdkon 5y agoWe could debate that for a long time, but my point was different: There's no sane function in today's PHP that parses ints and handles errors (defaulting to 0 doesn't count).
- Y-bar 5y ago> defaulting to 0 doesn't count Why this arbitrary restriction? A forced cast of a string to integer is always guaranteed to produce an integer.
- dvdkon 5y agoAnd a forced cast is therefore a bad way to generally parse a user-provided string to int.
- samus 5y agoAnd how are we supposed to distinguish that from a legit 0?
- Y-bar 5y agois_numeric() has been available since forever, and is intended for exactly the thing you appear to want to do. https://www.php.net/manual/en/function.is-numeric.php https://www.php.net/manual/en/function.is-numeric.php
- zerocrates 5y agoYou can kind of get this to happen in 8 and up: Doing math on a non numeric string is then a catchable TypeError so you can do 'x' + 0 in a try. Doesn't avoid other PHP numeric-string stuff like scientific notation and floats being accepted, though. Passing to a int-typehinted function param in 8.1 gets you closer (will complain about float strings) but is currently just a annoying-to-work-with deprecation notice. Presumably it will eventually also be a TypeError.
- deleted 5y ago[deleted]
- dsego 5y agoLib functions are vertically consistent with the underlying libraries. https://youtu.be/nmD1Q4FsXCc?t=845 https://youtu.be/nmD1Q4FsXCc?t=845
- dvdkon 5y agoYeah, PHP sometimes pretends it's a C derivative. I think it's a stupid idea most of the time, especially with regard to strings. C string handling isn't anything scripting languages should copy. Besides, PHP now has its own (partly duplicate) class-based stdlib for some things, why not be consistent and "replace" all of the old stdlib?
- dsego 5y ago> C string handling isn't anything scripting languages should copy. Or C-like imports, it's ridiculous tbh, inlcude, inlcude_once, require, require_once. My understanding is that PHP started as a basic templating language, a way to embed c function calls as tags in HTML. In that way it's ingenious, people keep reinventing it with JSX, filesystem routing etc. Right now I'm thinking PHP should've gone the other way. Instead of adopting features to resemble other general purpose languages (things like classes from java and so on) it should've doubled down on web stuff, like JSX - in the sense of having a nice syntax for partials/components, eg <php-component props /> instead of <?php echo php_component(props) ?> and other comfort features, to become a platform.
- qalmakka 5y agoWell, they basically took the __looks__ of Perl and bolted on a dynamically typed Java on top of it. I don't think there are languages more different in concepts and values than Perl and Java, and PHP is the result of that unholy mixture. Perl is crazy, but it has a very precise logic behind the madness. Java is boring and predictable. PHP is crazy while being completely random.
- TedDoesntTalk 5y agoThis is a good summary of PHP in the past and maybe the present. I think the PHP 10 years from now won’t have the craziness anymore, based on the current trend.
- zerocrates 5y agoThey've gotten more aggressive lately in wiping away the dusty corners of the language, little-used alternative syntaxes like these,some of the footguns. But nothing even approaching a full reorg/rename of the stdlib. I think the sense is doing something like that would get you into an undesirable "Python 3" type scenario. Instead, the sort of unceasing wave of deprecations leads to some make-work but doesn't seem to cause the same kind of long term resistance to updating.
- jwommack 5y agoThey pretty much already had the "Python 3" issue with PHP 6, the unicode PHP
- zerocrates 5y agoYeah, but it never came out. A bullet dodged.
- mschuster91 5y ago> But nothing even approaching a full reorg/rename of the stdlib. It's been a long tradition in the PHP world to keep the PHP side of a module somewhat consistent with the underlying C API that the module exposes. On the one side, people with a C background immediately find themselves at home in PHP - on the other side, "new" programmers coming from the Java, Go or the matured JS world are confused because of all the inconsistencies.
- chipotle_coyote 5y ago> there’s still no reasonable int parsing function! Well, I suppose it depends on how one defines “reasonable”, and perhaps how one defines “parsing” (e.g., what is it you’re trying to do). As a comment elsewhere observed, while (int)$val; will force a non-integer $val to be 0, if what you’re trying to do is determine whether $val is a string literal that represents an integer, you can use filter($val, FILTER_VALIDATE_INT); instead. That will return the integer if it is, and false (actual boolean false) if it isn’t. Is this the best way to do it? Probably not. But I think I’m okay with testing that filter in an if statement rather than wrapping the type casting in a try/catch block. However: > I'm not against change, but PHP devs should decide if they want to make code maintenance easier, or make PHP an actually good language. Right now, it's in a weird in-between state. I'm not a fan of coming across old PHP code and having to make a bunch of small changes to port it to supported PHP. If the dichotomy you pose in the first part is correct, then “coming across old PHP code and having to make small changes” is unavoidable if they’re striving for the latter. Given that they’re clearly not down for making radical changes that break everything everywhere all at once, then it’s going to be in a “weird in-between state” for years, isn’t it?
- tored 5y agostdlib will never change, because it would break every PHP project out there. Many of the previous deprecations as been relatively easy to handle, like switch from each to foreach, or make sure that you don't pass null to stdlib functions, but changing the stdlib itself would instead be a complete nightmare. Remember that many projects out there needs to support multiple PHP versions at the same time, it would be extremely confusing if the stdlib started to do subtle changes between versions and also hard to properly handle and detect. Like if you would swap $needle and $haystack for strpos(), it would be nightmarish to statically detect in an existing code base which is the correct order and quite hard for a human. Introducing aliases is also a bad idea, there already exists aliases in the stdlib and they only add confusion when reading code, that would be true for new aliases as well. Named arguments alleviates the problem with argument order in exchange for more verbosity. What PHP could do is to introduce primitive objects, e.g. $str->substr(...), however that would not guarantee a well designed standard library either, because RFC:s and emails is not a good forum for designing API:s. I think the correct solution is to implement operator overloading and let the community design a standard library/libraries. Because of the massive performance improvements of PHP the standard library is no longer required to be pure C, it can either be implemented in PHP or wrap the existing stdlib.
- qalmakka 5y agoWell, PHP approach to features is not really "pragmatic", it has boiled down for decades to basically adding whatever they could rip from somewhere else, without the slightest trace of logic behind it. When they deprecated and removed mysql_* way way more impactful IMHO, it basically broke half of the websites on the web. Was it worth it? Absolutely yes, because mysql_* functions were utter garbage and have caused unmeasurable damage over the years with their shoddy approach to sanitizing. Sometimes you have to atone for your sins, and that's what PHP has been doing in the last few releases.