Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 5.5

github.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: PHP 5.5

#81

Post by cousin_it »

kijin wrote: post #75
cousin_it wrote: post #64

Earlier quoted context omitted.

Hmm, but does it have to be that way? What if every new version of a programming language came with a tool that converted old source code to new source code, like Python's 2to3? That way you could cleanly handle removals, renamings and all sorts of other changes... maybe even provide implementations of old library functions in terms of new ones.

Automatically updating someone else's code is more difficult than it seems. Any Python project of significant complexity will need manual adjustment before or after passing it through 2to3, and even then you'll need to perform a lot of tests to make sure that everything behaves as expected. Similarly, the upgrade wizard in .NET always breaks a thing or two. I would expect a PHP upgrade wizard to fare no better. For e…

> how would you update them automatically if you decided to change the way htmlspecialchars() works?

I see two possible cases, the choice between which can be made by the converter developers or by the user (maybe via command-line flags to the converter):

1) If the new functionality is intended to be a drop-in replacement (e.g. it fixes a security bug), no change is necessary.

2) If we want existing programs to keep using the old functionality, you could automatically translate all cases like this (assuming we're translating from PHP7 to PHP8):

    echo $h('');  // PHP7 code
to this:

    echo php7_varcall($h, '');  // PHP8 code
To clarify, php7_varcall() is a function in PHP8. When it receives 'htmlspecialchars' as an argument, it calls the function php7_htmlspecialchars() which is a faithful rewrite of PHP7's htmlspecialchars() in PHP8.

> If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects.

In general, any php7_builtin() should be implementable in PHP8 somehow. If that's not possible, I'd say there's a gross design error somewhere.

> If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.

In general, if the implementation of php7_builtin() in PHP8 relies on some library, then that library should be included in the "compatibility library" required to run all converted code.

Re: PHP 5.5

#83

Post by tomku »

rjknight wrote: post #73
agwa wrote: post #48

Earlier quoted context omitted.

It seems like every major software project reaches a point where the major number just stops changing. Linux too - it became clear that it was going to be 2.6.X.Y forever, so they renumbered to 3.X.Y to make the version string shorter. I guess it's a sign of maturity: the project has reached a solid codebase with good development practices so there won't be any more overhauls that warrant a major number increase.

Chrome is a good counter-example, but I agree that it's rare.

I view Chrome (and Firefox now) as essentially having "Chrome" and "Firefox" as their major version numbers, if that makes sense. It's so unlikely that they'll break compatibility that any such break would probably result in a completely new product/branding.

Re: PHP 5.5

#84

Post by nahreally »

Udo wrote: post #69
dkhenry wrote: post #49

And what I still don't see is anything saying they are taking their performance problems seriously. Still nothing saying they are fixing their documentation. Nothing addressing their hodgepodge of legacy code and mixed methods of implementing features. Its like their upset that people have moved on, but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the la…

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well. I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers t…

What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)

Re: PHP 5.5

#85

Post by rmccue »

dave1010uk wrote: post #6
thejosh wrote: post #3

Biggest change? - Drop Windows XP and 2003 support

Most interesting things for me: * PHP is getting the yield keyword (i.e. generators and coroutines), which many other languages have had for a while. * A sensible and simple built-in password hashing API * Error when using the deprecated mysql extension, which should hopefully get more people moving to PDO (e.g. WordPress: http://core.trac.wordpress.org/ticket/21663 )

I'm trying to push for that WordPress ticket, but it's unlikely that we'll get any significant traction for a while. The database class in WP (apart from being fairly horrible) is a huge component to make major changes to like that, and we have to consider backwards compatibility.

Here's hoping it gets merged in the next 5 major releases. I'm not holding my breath.

Re: PHP 5.5

#88

Post by Udo »

nahreally wrote: post #84
Udo wrote: post #69

Earlier quoted context omitted.

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well. I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers t…

What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)

There is not really a lot of substance in those assertions. There might be more legacy PHP codebases than, say, Ruby ones, but that's going to change as Ruby ages. The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones. Same goes for RoR and Python/Django by the way as they become mainstream. As you move away from the cutting edge as successful projects do, there is always an influx of less-skilled developers trying to hop onto the wagon. That doesn't say anything about the things good developers can do with the right tools.

In the end, there is just nothing constructive here. PHP haters, fashionable as they may be, will agree with you. PHP users will roll their eyes and move on. And very little factual arguments have been exchanged beyond useless posturing.

Re: PHP 5.5

#89

Post by jtreminio »

nahreally wrote: post #84
Udo wrote: post #69

Earlier quoted context omitted.

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well. I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers t…

What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)

You're living in a HN bubble if you seriously think no new projects are being created in PHP, or if you think there are no valid use cases for PHP in modern applications.

Simply take a look at popular job sites - you don't even have to look at Monster.

PHP devs may be the cheapest as a whole because there's so many. If you're dead-set on finding a Go programmer they will come at a cost because there's so few.

Once you get into the higher level of skill, though, it starts evening out. IIRC the average senior salary for Ruby/RoR devs is only ~$5,000 more than a PHP dev.

Re: PHP 5.5

#90

Post by Udo »

dkhenry wrote: post #78
Udo wrote: post #69

Earlier quoted context omitted.

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well. I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers t…

When I say documentation I mean the internals of PHP. Here is their documentation page http://www.php.net/manual/en/internals2.apiref.php

I must confess my knowledge about PHP internals and the perspectives of being a core runtime developer is pretty much non-existent. All I have to go by are the API and language features exposed to any web app developer - and that paints a different picture. Are you, by chance, a core contributor?
Post reply on HN