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

The new PHP

programming.oreilly.com

Post reply on HN
Print view View original

11–20 of 203 posts

Re: The new PHP

#11

Post by nkozyra »

awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

I think at this point simply removing critical, old bugs, unicode support and removing and/or restructuring the cruft of the standard library would be enough.

Unfortunately, the biggest hurdle at this point is reputation. No full or dot release will change that.

Re: The new PHP

#13

Post by ajankovic »

Gigablah wrote: post #4
d23 wrote: post #2

> It contains powerful new features and helpful developer tools, such as a built-in web server I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. How long until we start having security releases for the PHP web server, because so many clueless devs decid…

What makes you think a "clueless" dev is going to find out there's a built-in web server in the first place?

Or that dev is going to know what is web server.

Re: The new PHP

#14

Post by mgkimsal »

awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

Make the "stdout == response body" an explicit option

Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be.

"== should work like ===". Why? If you want ===, use ===. But given that HTTP, the lingua franca of the web, is typeless, and PHP is targeting web developers, having a language that doesn't enforce types in all cases isn't all that bad.

Re: The new PHP

#15

Post by lukeholder »

All this is very true.

Modern PHP is not the PHP of yesteryear. With Composer for dependancy management and sticking to the PSR's you can build very stable, testable, and modern applications that change minds about PHP.

Re: The new PHP

#16

Post by mehwoot »

maratd wrote: post #5
d23 wrote: post #2

> It contains powerful new features and helpful developer tools, such as a built-in web server I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. How long until we start having security releases for the PHP web server, because so many clueless devs decid…

The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…

Just because a tool can be misused is not an argument against it nor its inclusion.

I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make.

I'd rather a builder use a second hand hammer to nail something than try doing it with a jackhammer.

Re: The new PHP

#17

Post by rubiquity »

> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style.

"The new Java"

It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I think PHP would do itself a big favor by cleaning up its main APIs and standard library first. Maybe they will do that in PHP 6, since I doubt they want to break APIs in minor releases.

Re: The new PHP

#18

Post by lotsofcows »

awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

"Tighten equivalence requirements" But PHP is a great tool for working with the messy world of the web. Being able to type !$anyvariable is expressive, obvious and straight-forward. I don't care what type it is. Unless, I do; then I use ===

Re: The new PHP

#20

Post by awestroke »

mgkimsal wrote: post #14
awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

Make the "stdout == response body" an explicit option Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be. "== should work like ===". Why? If you want ===, use ===. Bu…

1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates

2: PHP, however, has types. == is wildly unpredictable

Post reply on HN