12 ms·

After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. But

• birkbork 12y ago
  If you want to order your program in a specific way, you introduce the appropriate level of abstraction. Same as with any other language. EDIT: i totally agree that the standard functions are a complete mess in PHP. But they have to stay around for backwards compatibility. Have a look at the SPL classes: http://php.net/manual/en/book.spl-types.php http://php.net/manual/en/book.spl-types.php
  • flatline 12y ago
    When you're talking about the core libraries that ship with the language, it seems unreasonable for every PHP developer to have to introduce it themselves.
  • cdmckay 12y ago
    This simply isn't possible in a way that would be convenient. For example, how would I make a string abstraction? Create a class? Ok, so we have: $str = new String("foo") $str->replace(...) over $str = "foo" str_replace($str, ...) This is fine, if we ignore the fact it's much slower. Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do $str->concat($str2)->concat(new String(" "))->concat($str3) instead of $str . $str2 . " " . $str3 There's things you can do to make the API a little bit more convenient (i.e. allow it accept PHP strings, etc.), but ultimately it becomes a huge pain, especially if you want to start interoperating with other libraries that are using a different abstraction or, more likely, using the regular PHP types and functions.
    • maaaats 12y ago
      Well, it doesn't have to be slower. The generated bytecode can be the same. And there could still be syntactic sugar left to allow for easy concating.
    • imaginenore 12y ago
      Javascript doesn't have operator overloading, but it doesn't stop you from doing "foo".replace('oo', 'ood') + " tasty" I don't see why PHP can't treat strings specially as well.
    • pippy 12y ago
      Many PHP data types (such as mysqli etc) have been made into objects, and I agree 100% that it's silly to do this with strings. Ease of string manipulation is a PHP strong point. You'll be giving PHP devs a loaded gun by allowing them to register primitive types (as proposed by nikic). Most frameworks would add to them, but I know some people would change default behaviour to 'fix' issues such as db character encoding issues which would make debugging hell.
    • chriswarbo 12y ago
      > Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do > $str->concat($str2)->concat(new String(" "))->concat($str3) > instead of > $str . $str2 . " " . $str3 Erm, no you wouldn't. What's wrong with either of these? String::implode($str1, $str2, new String(" "), $str3); String::sprintf("%s%s %s", $str1, $str2, $str3); Of course, if you want to add operator overloading, you might as well overload '"' as well, so you can use "foo" instead of new String("foo"). Personally, I'd prefer operators to have function equivalents, so your example could be written: array_reduce([$str1, $str2, " ", $str3], '.', ""); I've raised this at https://bugs.php.net/bug.php?id=66368 https://bugs.php.net/bug.php?id=66368
      • Mikushi 12y ago
        Please no. This is awful verbose syntax. Use Java if that's what you want. This is not PHP, this will never be PHP. Some people need to remember the purpose for which PHP was started and what it still is great at: making websites. You guys are stuck in high brow academic debate on the semantic of a language that was born before many of us started coding, and that helped the web become what it is today. And that has come a long way. I'm not saying to stop improving the language, but as someone who has used PHP for 15 years, all the issues I see come up constantly in threads like this are non issues, never encountered them in any web situation, you have to seek these "bugs"/annoyance, or be seriously inexperienced with PHP, or as I've been saying for years any time I do conferences: you are using PHP wrong. So please, keep your verbose syntax in other languages that "need" it, while there are improvement to be made on PHP, this is not an area that needs one. Also, looking at your bug submission/request, I share krakjoe sentiment: what the F are you trying to achieve? Seriously, I am curious. To me it screams wrongly used PHP.
• cdmckay 12y ago
  I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myStr.replace() As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals
  • mreiland 12y ago
    right, and then it becomes even less readable because someone calls in the namespace somewhere and half of your project uses 1 version, half the other. No, just stick with the consistency of using the stdlib as is. If someone really has a problem with these specific issues they don't need to be developing, period.
    • cdmckay 12y ago
      I would like to think that in any sane project they would choose one of the namespaces and stick with them. Moreover, I think that as you deprecated the older namespaces, this problem would go away. You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're trying to make it sound. I'm not really sure I follow the logic that if someone has an issue with the state of a programming language then they shouldn't be developing. How does that make any sense?
      • mreiland 12y ago
        because you're involved in a strawman. funny how that works.
    • bitwalker 12y ago
      It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.
• TazeTSchnitzel 12y ago
  Nikita proposes methods on primitive types: http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html http://nikic.github.io/2014/03/14/Methods-on-primitive-types... Myself, I like this proposal.
  • agumonkey 12y ago
    Soon all dynamic languages will be one. Except for the method call syntax.
    • Shorel 12y ago
      Actually, that's Uniform Function Call Syntax http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327... And it doesn't make a language 'dynamic'. The language I found with UFCS is both static and compiled.
      • agumonkey 12y ago
        That's not what I meant. PHP code was built around its SPL, if they accept nikic proposal, people will code using base types with similar operations set found in many dynamic languages. What's left is [1,2,3]->slice(1,2) versus [1,2,3].slice(1,2) ps: dynamic can be compiled and compiled can be interpreted, so I understand that it is unrelated.
      • recursive 12y ago
        Walter notes two advantages of that scheme over extension methods. One of them is that extension methods can not be called with the standard prefix notation. This is not actually true, at least in the languages most known for extension methods, Visual Basic and C#.
    • kenshaw 12y ago
      You mean all dynamic languages are Lisp?
      • 12y ago
• Arnor 12y ago
  Fun with PHP: $a = 'b'; $b = 'a'; echo $a."\n"; >>> b echo $$a."\n"; >>> a echo $$$a."\n"; >>> b Yaaa $obj = new StdClass(); $obj->x = 1; function x_plus_one($obj) { $obj->x++; } x_plus_one($obj); var_dump($obj); >>> object(stdClass)#1 (1) { >>> ["x"]=> >>> int(2) >>> } Huh? A local change to the object changed the object outside the local scope? It must have been passed by reference... function null_the_object($obj) { $obj = null; } null_the_object($obj); var_dump($obj); >>> object(stdClass)#1 (1) { >>> ["x"]=> >>> int(2) >>> } Huh? Before when I edited the object within the function, the object I passed in was edited, what gives? We don't actually pass objects to reference in PHP, we pass them by "object reference." But don't worry, you can still null objects that get passed to you: function null_the_object_2(&$obj) { $obj = null; } null_the_object_2($obj); var_dump($obj); >>> NULL Sure it's not as bad as it used to be. Yes, a disciplined developer can make good software with it, but it's still a pretty quirky.
  • opendais 12y ago
    To be fair, all languages are "a bit quirky". It gets worse when you start including things that are in the PHP stdlib but aren't in other languages by default. [e.g. When they basically re-implement how php-fpm handles requests and thread safety]
    • Arnor 12y ago
      >>> To be fair, all languages are "a bit quirky". Agreed. These are just a few quirks in PHP I find amusing.
      • opendais 12y ago
        They are amusing indeed. :)
      • Zancarius 12y ago
        I'm sure you've already seen this (it's been around a while), but if not, you'll find it amusing: http://www.phpwtf.org/ http://www.phpwtf.org/ Last I checked, it wasn't quite as good as wtfjs, but it looks like quite a few new surprises have been added rather recently. Edit: Correction, there's only one new entry as of this year, which is a shame. :)
• wiremine 12y ago
  > It's changed a lot since I first used it. Have any good examples? I haven't used the language in years, would love to see what "modern" PHP looks like. (Seriously, not trolling at all)
  • speg 12y ago
    http://radar.oreilly.com/2014/03/the-new-php.html http://radar.oreilly.com/2014/03/the-new-php.html I just came back to PHP myself after 4 years away and have been pleasantly surprised. A lot of it has been community driven with things like the PHP-PSR standards and Composer, in additional to all the language features that have hit since 5.3
  • hrktb 12y ago
    Apart from the language in itself, the ecosystem has matured leaps and bounds. Symfony is the poster child of the new frameworks: easy to use, flexible and powerful. I haven't used rails but I heard it's going the same direction. Sometimes I feel we're getting too close to Java territory in terms of abstraction and reliance on libraries, but that would also be a sign of maturity.
    • adamors 12y ago
      Symfony2 is definitely not going in the direction of Rails. It was and will be Rails' opposite: built around a dependency injection container, favors configuration over convention and uses as little magic as possible.
  • vjeux 12y ago
    I made a blog post that compares Hack and the new Javascript specifications ES6 and ES7[1]. They have a lot of features in common. [1] http://blog.vjeux.com/2014/javascript/hack-is-to-php-what-es6-is-to-javascript.html http://blog.vjeux.com/2014/javascript/hack-is-to-php-what-es...
  • smacktoward 12y ago
    PHP the Right Way is a good place to start: http://www.phptherightway.com/ http://www.phptherightway.com/
• stan_rogers 12y ago
  The last goddamned thing I want in what is fundamentally a string-spitting language is to have the string features wrapped. Do what you will with the rest of the modules, but leave the damned strings alone.
  • rmrfrmrf 12y ago
    "Foo".replace("o","O"); Not a big deal.
• donatj 12y ago
  Despite peoples grumblings about parameter order the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack. Once you know that its not that difficult. Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, whereas on map you can map a list of arrays.
  • randomdrake 12y ago
    > the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack. So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle. I'm not really commenting on whether one should have to remember this, only that it helps if you need to remember it.
    • colordrops 12y ago
      > searching for a needle in a haystack > searching in a haystack for a needle wait, what's the difference?
      • deleted 12y ago
        [deleted]
      • cglace 12y ago
        The order of the words.
  • chriswarbo 12y ago
    Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right: $asBools = partial_apply('array_map', 'boolval'); $asBools(['hello', '', 'world']) === [true, false, true] $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true] array_filter and array_reduce get this wrong, requiring awkward argument-shuffling: $inverseFilter = partial_apply(flip('filter'), 'boolNot'); $inverseFilter([-2, -1, 0, 1, 2]) === [2 => 0] array_keys($inverseFilter(['foo' => true, 'bar' => false])) === ['bar'] $allTrue = partial_apply(flip(partial_apply(flip('array_reduce'), 'boolAnd')), true); $allTrue(['hello', 'world']) === true $allTrue([true, true, 0, true]) === false Note that a) if specialisation was easy, there would be no need for default arguments and b) having default arguments at the end is exactly the wrong way around for making specialisation not suck. We could sweep this under the rug by saying it's awkward because it's not idiomatic PHP; but one reason why it's not idiomatic is that it's awkward! Just look at Javascript, where functions are slightly less awkward; there are lots of functional APIs in wide use, eg. Underscore.
• 59nadir 12y ago
  > After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it. Criticism doesn't become unfounded because things become better. Things become better because of criticism.
  • lambada 12y ago
    But if things have got better, then perhaps the criticism is no longer valid? Criticism leads to things getting better which leads to the (original) criticism having been resolved and no longer applicable to the current versions. (I'm not going to weigh in on whether any of the criticisms have been resolved in PHPs case specifically, as I've been away from PHP long enough to not be able to talk on any problems with the current language)
    • dspillett 12y ago
      > But if things have got better, then perhaps the criticism is no longer valid? Part of that is due to the share amount of code out there doing things bad ways that were almost encouraged years ago, and tutorials still out there teaching people to do things the old less good ways. Of course a lot of it is people who haven't touched the language for many years (such as myself) who are at this point a lot less informed than they think they are! Another issue is that the new frameworks seem to get the positive news, not the core. The language use to describe PHP related libs/frameworks is different in my experience which makes a perception difference: PHP frameworks are often referred to as "making PHP behave" or "removing the cruft from your workflow" where frameworks for other platforms would be described as "helping you make the most of <platform>" and "increasing your efficiency".
  • mreiland 12y ago
    things do not merely become better because of critism, criticism becomes worse as things get better. https://www.youtube.com/watch?v=b5I94bT23cQ&t=1m34s https://www.youtube.com/watch?v=b5I94bT23cQ&t=1m34s
• joepie91_ 12y ago
  Having used PHP actively for 9 years, having seen it 'evolve', and having started with a number of different languages/platforms (Python and Node.js in particular), I can say without a doubt that PHP is still awful. Yes, things are being improved. But in terms of language usability and consistency, PHP is still miles behind pretty much everything else, especially given the slow deployment of new versions of PHP. As for "unfounded criticism"... some particular inconsistencies have been fixed, but the original criticisms are still valid - they just apply to different things now. If you look into the way the PHP interpreter actually works internally, you'd rapidly find that suggestions like "methods one can call on the objects themselves" is more or less an impossibility. As far as I'm aware, rather than treating base types as special kinds of objects, PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture. I'm absolutely not an expert on the internals of PHP - but from the design flaws that leak through at times, it becomes obvious that the PHP internals consist of a lot of hard-to-maintain code bloat, and that code reuse/abstraction is not as common as it should be. One particular example I ran across myself was this: http://www.reddit.com/r/lolphp/comments/1twal5/really_php_really/ http://www.reddit.com/r/lolphp/comments/1twal5/really_php_re... (the paste no longer exists, sorry for that).
  • deleted 12y ago
    [deleted]
  • wvenable 12y ago
    > PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture. Most platforms treat scalars as entirely different types at some level and then paper over the differences. As for the PHP architecture, I've actually looked into this, and it would take only one small change to the method-call code to add methods to scalars. In fact, the design of PHP makes this surprisingly easy to add.
• jqueryin 12y ago
  The short answer is yes, they continue to wrap older code in new neatly-packaged libs and extensions. For recent examples, you can check out these links: http://php.net/manual/en/migration54.classes.php http://php.net/manual/en/migration54.classes.php http://php.net/manual/en/migration53.classes.php http://php.net/manual/en/migration53.classes.php http://php.net/manual/en/migration53.new-extensions.php http://php.net/manual/en/migration53.new-extensions.php In 5.5 they didn't add a bunch of new extensions or classes, but they did add generators and finally. http://php.net/manual/en/migration55.new-features.php http://php.net/manual/en/migration55.new-features.php They haven't taken to packaging up arrays or strings yet, but I wouldn't doubt you'd see it over time.