Live data from Hacker News

Announcing a specification for PHP

hhvm.com

191–200 of 263 posts

Re: Announcing a specification for PHP

#191
post #168
post #23

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 the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…

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, wh…

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.

Re: Announcing a specification for PHP

#192
post #145

Earlier quoted context omitted.

That's why I said "presumably", and only referring to posting on HN, specifically (i.e. could have had previous accounts). This is very subjective, but I find people who (again, presumably) haven't been involved in a community who all of a sudden start right off the mark by posting in that community with a phrases like "HN hipsters", to be rude.

Alright, I'll say it then. I've had an account for 1300~ days, 3 times as long as you and I've been reading for longer then that. HN hipsters dislike PHP.

It is not a matter of what was said, it's a matter of the fact that it was said by a (presumably!) newcomer.

I'm not a web-developer (or whatever you would classify PHP as), so I don't feel hit with the remark.

Re: Announcing a specification for PHP

#193
post #145

Earlier quoted context omitted.

That's why I said "presumably", and only referring to posting on HN, specifically (i.e. could have had previous accounts). This is very subjective, but I find people who (again, presumably) haven't been involved in a community who all of a sudden start right off the mark by posting in that community with a phrases like "HN hipsters", to be rude.

I don't think it was an attempt to be rude. "Hipster" is a term commonly used to describe those who advocate so-called "Web 2.0" technologies like Ruby on Rails, JavaScript, HTML5, NoSQL, and so on. These people openly admit that they dislike the previous generation of web development technologies built around languages/platforms like Perl, PHP, and Java. There are many of those people here, so it makes sense to refe…

I've only seen "hipster" being used in a derogatory way on the Internet. But maybe this is some more HN-specific way that I haven't seen/before, which shows that I'm too inexperienced on here. :}

Re: Announcing a specification for PHP

#194
post #174

Earlier quoted context omitted.

You are spot on, Nginx+HHVM is really fast. I am an early adopter of HHVM (since Dez 2012) and it really shines on sites with thousends of requests per seconds. I heard PHP 5.5+ on Nginx (FPM) is fast as well. And I prefer PHP as I can code websites without the need of frameworks (PHP is "the framework") with a C/C++ like syntax. The idea of libraries is much older than frameworks, and in the end libraries are so muc…

> And I prefer PHP as I can code websites without the need of frameworks That either means A) you re-invent the wheel every time you start a project or B) you have your own implementation of commonly used items (your own framework) I personally would rather have a framework vetted & maintained by thousands of other developers than one I put together myself.

PHP, Node.js, Go and OpenResty have a versatile ecosystem with both libraries and optional (micro) frameworks.

I prefer the newer trend of micro frameworks and for simple websites just raw PHP 5.3+.

Re: Announcing a specification for PHP

#195
post #136
post #37

Earlier quoted context omitted.

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

or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.

It's not legit to error-out for eval, since PHP has all kinds of eval-like things.

For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example:

    $my_anon = function() {};

    function my_named() {}

    // Valid
    array_map($my_anon, []);

    // Invalid
    array_map(my_named, []);
As a workaround, whenever PHP sees a string when it's expecting a function, it will try to find a global function with a name matching the contents of the string. In other words, we can do:

    // Valid
    array_map('my_named', []);
This is basically a weak form of eval: taking a string of PHP code ('my_named') and getting back the value it evaluates to (the my_named function). If you error-out for eval, you have to error-out for this, since the content of strings is runtime information and there's no way you can infer it well enough. For example:

    function smart_replace() {
      $args = func_get_args();
      $func = array_shift($args)? 'str' : 'preg';
      return call_user_func_array("{$func}_replace", $args);
    }
Other eval-like things in PHP include variable property lookups, variable method calls and "variable variables":

    $foo = "hello";

    $object1->$foo = $object2->$foo;  // Sets $object1's "hello" property to $object2's

    $object3->$foo();  // Calls $object3's "hello" method

    $bar = "foo";
    echo $$bar;  // Outputs hello
One interesting fact about these features is that, since they're not as powerful as a real eval, it can often be perfectly safe to supply them with unvalidated user input:

    array_map('str_' . $_GET['string_function'], $my_array);
There's no way we can swap out things like this reliably, and remember that these are not just "crazy uses of eval", they're officially sanctioned ways of working, which in some cases (eg. function names in strings) have no alternatives (short of redefining your own standard library).

Re: Announcing a specification for PHP

#196
post #23

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 the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrapper…

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_re... (the paste no longer exists, sorry for that).

Re: Announcing a specification for PHP

#197
post #46

Earlier quoted context omitted.

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

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)->conc…

> 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

Re: Announcing a specification for PHP

#198
post #46

Earlier quoted context omitted.

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)->conc…

> 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 over…

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.

Post reply on HN