Looks like PHP spec is about twice smaller than ECMAScript 5.1 ( http://es5.github.io/ ) ~42K vs ~82K words.
The ES5 spec specifies its whole standard library, however ;)
Announcing a specification for PHP
201–210 of 263 posts
Re: Announcing a specification for PHP
#202Earlier 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.
To be fair, PHP's stdlib is essentially a Web framework. It comes with $_SERVER, $_GET, $_POST, header(), etc. built in, which other languages (Python, Haskell, Perl, etc.) would define in a framework. Hence there's no need to redefine stuff over and over. Hell, PHP is even a templating language by default, thanks to its tags.
Of course, this doesn't answer the related questions: is PHP's built-in framework any good? Is it a good idea to include a Web framework in all scripts (even non-Web ones)? Is it a good idea to write all application logic inside giant tags in template files?
Re: Announcing a specification for PHP
#203After 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 f…
[deleted]
Re: Announcing a specification for PHP
#204After 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…
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/migration53.classes.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
They haven't taken to packaging up arrays or strings yet, but I wouldn't doubt you'd see it over time.
Re: Announcing a specification for PHP
#205Earlier quoted context omitted.
> 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 c…
> To me it screams wrongly used PHP.
Of course it's wrongly used, since it doesn't work (hence my request to make it work).
The issue is not whether we should write such code now (we obviously shouldn't, since we'll hit all kinds of language problems); it's whether we'd like to write such code in the future (in which case we need to fix those problems now). Personally, I would like to avoid redefining built-in capabilities over and over.
As for what I'm trying to achieve, the same as everyone else: clean, understandable, maintainable code.
Here's something I ran across this week. I'm instantiating a class $class (read from a config file) and need to inject dependencies ($dep_classes, read from a config file) into the constructor. How to do it?
$deps = [];
foreach ($dep_classes as $dep_class) {
$deps[] = new $dep_class;
}
$instance = new $class(...$deps);
$deps = array_map(function($dep_class) { return new $dep_class; }, $dep_classes);
$instance = new $class(...$deps);
However, it's clear that, again, we're reinventing the wheel. array_map passes the class names to its callback, so why are we passing them to "new" ourselves?
$deps = array_map('new', $dep_classes);
$instance = new $class(...$deps);
- Use a foreach loop to duplicate the functionality of array_map. - Define a new function which behaves exactly like "new".
Perhaps 15 years with PHP has given you a "gut feeling" to avoid programming styles which will inevitably run into problems; I've certainly got such a feeling after 4 years. While avoiding those problems is useful to get a job done today, it would be even better if we didn't have to worry about them tomorrow.
There's no point adding features like array_map, anonymous functions, etc. to the language if we all have to learn to avoid them to avoid parser errors.
Re: Announcing a specification for PHP
#206This should help the PHP-NG project too. I was a bit worried to see they were doing large refactorings to increase speed when the PHP test suite only has about 30% code coverage.
Re: Announcing a specification for PHP
#207Earlier quoted context omitted.
> PHP is quite a capable language I don't think anyone is complaining that it's not turing complete (or whatever), it's all the times php has dropped the ball in the std library, both with respect to being consistent with itself and just being plain broken. I don't think any sane person would switch from a language INTO php, given how many languages that are just as capable as php without having all of its various hi…
For me this is the important part. I have a team with java/php/javascript experience. PHP will not be an option for my use case. I need a json based rest interface with a decently discoverable web interface. Java has stupidly powerful rest interface libraries with jersey or full application servers, and javascript has hugely powerful frontend interfaces with angular or other frameworks, based on a strong rest interfa…
That's the beauty of an API. It doesn't really matter what backend language you decide to use. To the front-end client, it's just good old endpoints sprinkled with JSON.
Re: Announcing a specification for PHP
#208This is great news, now we just need to lobby for the creation of this specification in machine readable files, using something like the K Framework, instead of using the usual wall of text.
Re: Announcing a specification for PHP
#209Earlier quoted context omitted.
I don't want root access. I want to sign up, upload my files through FTP and have it working instantly without having to worry about anything else.
... which you can also do on platforms like digitalocean. Just spin up a preconfigured dokku droplet and git push.
> Just spin up a preconfigured dokku droplet and git push.
Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.
Re: Announcing a specification for PHP
#210Earlier quoted context omitted.
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…
The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.