[deleted]
PHP 5.4.0 released
91–100 of 103 posts
Re: PHP 5.4.0 released
#92Earlier quoted context omitted.
How is ' Also, Chained string offsets - e.g. $a[0][0] where $a is a string - now work. I have no idea how is that supposed to work. What should be the outcome on, say: $a = "foo"; $a[0][0] What about (assuming $a is still "foo"): $a[0][1] etc.?
> How is ' When you share your code with various clients (open source, software seller, ...), you can not assume that short array are on, thus you have to use everytime instead of the shorter . Having the second syntax always working solves that, this is on the same level as the short array syntax change, removing a hurdle and letting you concentrate on more important stuff. > $a = "foo"; $a[0][0] $a is a string "foo…
> thus you have to use everytime instead of the shorter
Is this really a huge concern? I guess I just have $tockholm syndrome at this point, and am used to writing explicitly every time, precisely for the reasons you mentioned. It's one less thing to worry about.
Re: PHP 5.4.0 released
#93I'm glad to see the short array syntax. Having strayed from PHP for a while to work on Ruby and JavaScript I'm really enjoying the ability to leave out semicolons in unambiguous end-of-line situations. Would love to see that make it into PHP at some point.
Isn't that a bit like leaving a loaded handgun laying around? It's unambiguous today, but what if someone else starts working with your code and it's no longer unambiguous?
(edit: talking about JS only.)
Re: PHP 5.4.0 released
#94Earlier quoted context omitted.
While I agree that it makes it easier to hack in that functionality, it would still be very useful to have named parameters for functions that don't implement that functionality. For example, fgetcsv takes parameters for delimiter, enclosure, and escape char (as of 5.3). Right now, if I want to specify a different enclosure, I'm forced to specify a delimiter even if I still want to use the default. I'd much prefer th…
> While I agree that it makes it easier to hack in that functionality, it would still be very useful to have named parameters for functions that don't implement that functionality. Absolutely. But PHP devs have repeatedly refused to support named parameters so this is a good enough fix.
> this is a good enough fix.
The story of PHP's life.
Re: PHP 5.4.0 released
#95Earlier quoted context omitted.
Also it is faster and much better on memory consumption (depends on app of course, but 10-20% speedup and 20-30% less peak memory have been observed on some mainstream apps).
Are these numbers based on most previous versions of PHP? I'm on 5.3.10, do you think if I upgraded I would see similar improvements?
Yes, most probably you will see significant improvements. Of course, it depends on your app - if your app spends 99% of time in SQL database calls, PHP can do nothing about it. But PHP part would be faster and take less memory.
Re: PHP 5.4.0 released
#96Earlier quoted context omitted.
Books... not so much. I have another idea: you could check out an MVC-framework like codeigniter or CakePHP. There are numerous tutorials about them, and they give you the added benefit of working with an MVC pattern (knowledge you can use in other languages and frameworks as well, such as Ruby on Rails) and working Object Oriented. In my opinion, a big drawback of PHP is that it's so easy to screw up because it's ea…
CodeIgniter and CakePHP are great examples of code badly brought forward into PHP5 from PHP4 roots. I wouldn't recommend either to either a novice or an expert; CodeIgniter is a fantastic example of out-of-date practices and CakePHP an example of writing such abjectly slow code that everybody else benchmarks against you to look good. If you're going to use PHP5, Symfony2 is a well-reasoned, best-of-breed system.
I'd also recommend Kohana. It was originally a fork of CodeIgniter, but version 3.0 was a complete rewrite for PHP5. Compared to Symfony, it's more of a barebones framework.
Re: PHP 5.4.0 released
#97They shipped it with 82 failing tests.
http://gcov.php.net/viewer.php?version=PHP_5_4
Why even bother having a test suite?
Re: PHP 5.4.0 released
#98They shipped it with 82 failing tests. http://gcov.php.net/viewer.php?version=PHP_5_4 Why even bother having a test suite?
I'm not sure what's more worrying:
* 82 failing tests
* 44 expected test failures
* 1119 compiler warnings
I want to believe that PHP is growing up, but I have to admit I'm not convinced.
Re: PHP 5.4.0 released
#99Earlier quoted context omitted.
CodeIgniter and CakePHP are great examples of code badly brought forward into PHP5 from PHP4 roots. I wouldn't recommend either to either a novice or an expert; CodeIgniter is a fantastic example of out-of-date practices and CakePHP an example of writing such abjectly slow code that everybody else benchmarks against you to look good. If you're going to use PHP5, Symfony2 is a well-reasoned, best-of-breed system.
I'd also recommend Kohana. It was originally a fork of CodeIgniter, but version 3.0 was a complete rewrite for PHP5. Compared to Symfony, it's more of a barebones framework.
I wouldn't. Kohana's track record of cavalier response to security concerns is off-putting and their code is not particularly impressive.
There's a reason people who use PHP are getting on @fabpot's train and not Kohana's, and that's because Symfony2 does much, much more right than anyone else in the conversation.
Re: PHP 5.4.0 released
#100Earlier quoted context omitted.
Good tools complain about <?= because it does not start with a named target. A lot of people just haven't read about the idea behind processing instruction syntax, which is also why we keep seeing mistakes like <%.
A PHP script isn't an XML document, so processing instructions aren't really relevant. Even if your script is outputting XML, the script itself isn't going to be read by an XML parser.
It can if you want. It's not that hard to make documents which are valid before and after scripts run. This enables many more tools to work with them.