Live data from Hacker News

PHP 5.5

github.com

101–110 of 112 posts

Re: PHP 5.5

#101
post #90
post #78

Earlier quoted context omitted.

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?

I have contributed patches to the PHP core, but I am not a core developer.

Re: PHP 5.5

#102
post #93

Am I the only one thinking PHP needs more stuff removed rather than added ?

Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth. As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase…

That's pretty much what I had in mind with this comment, I should have expanded it a bit. What grates on my nerves when writing PHP is indeed the awfully inconsistent standard library. Though some syntax choices (namespaces for instance) are also pretty weird.

Re: PHP 5.5

#103
post #95
post #80

Earlier quoted context omitted.

I do respect the work they have done to the language, and I have also spent many hours contributing back to PHP and the various projects in the PHP community, however that doesn't change the fact that the _community_ collectively has a hard time dealing with the hard issues that need to be solved. Proof of that is the response you see right here on this forum. Mention how PHP's internals are lacking and get told how…

> Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform. I'm sorry, but given that PHP the platform (forgetting about gripes with the language syntax for a moment) has been used on major projects for years, what more significant progress do you want? Your talking about it as if it needs to prove itself as a viable technology, when clearly this is not th…

^^^^^^ This is the attitude I am talking about. Clearly since it's popular then there is nothing wrong with it. Thats total BS. There are tons of things wrong with it. Yes people do really cool things with the language and the run time, but just because someone using it doesn't make it _good_.

Re: PHP 5.5

#104
post #93

Earlier quoted context omitted.

Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth. As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase…

That's pretty much what I had in mind with this comment, I should have expanded it a bit. What grates on my nerves when writing PHP is indeed the awfully inconsistent standard library. Though some syntax choices (namespaces for instance) are also pretty weird.

Maybe someone should fork the parser/lexer and see what a cleanup can accomplish. There are a few tons of "features" I would delete immediately. And I agree the namespace syntax is horrible.

Re: PHP 5.5

#105
post #26

Seems like a bunch of really welcome improvements. Wish I hadn't known about them though, as I probably won't be able to use them in our production environment for the next 2 years or so.

Can I ask why it will take so long? I'm working on a medium to large scale project and we will be likely rolling the new version out to our staging environment within a week and assuming everything goes smoothly to the production environment not long after that.

My biggest nemesis: legacy...

Re: PHP 5.5

#106

Earlier quoted context omitted.

If michh is working on plugins for other people, shared hosts can be pretty behind on their PHP versions. I just had to backport a wordpress plugin to 5.2(!), which came out in 2006. EDIT: meant PHP versions, not plugins.

Thats the curse of distributable code unfortunately. And PHP only makes it worse because it's old versions are absolutely terrible...

> And PHP only makes it worse because it's old versions are absolutely terrible...

You just need to put your foot down. 5.2 is absolutely too much, I would never develop for it. Just tell them to stop being so damn cheap and upgrade to a decent hosting company. AWS is free for a year for new clients, there's no reason for them not to switch to something decent.

Re: PHP 5.5

#107
post #100

Earlier quoted context omitted.

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

So your solution is to add more functions, like php7_htmlspecialchars(), php7_htmlentities(), etc. whenever a function needs to be deprecated, just like PHP historically added functions like mysql_escape_string(), mysql_real_escape_string(), etc.? I don't think that will help the language and its ecosystem at all. I can almost see the tutorials in my mind: "If you upgrade to PHP 8 and your function call suddenly star…

Functions like php7_htmlspecialchars() wouldn't live in the standard library, they would live in the "compatibility library" instead. That might help discourage new users from using them and mentioning them in tutorials.

I agree with your point that bulletproof conversion will make reflection-heavy code less readable. But still, if we can make a bulletproof converter that works on 100% of old code and leaves simple code relatively unchanged, doesn't that open up some nice options for everyone?

- Users who don't care about code quality, and just want their old code to work, will be happy because they will have a push-button upgrade solution.

- Users who care about code quality will also be happy, because they can run the converter and have a complete working program right away. Afterwards they can modernize it piece by piece, at their own pace, having a complete working program at each step. Without the converter they'd be stuck doing a full rewrite.

- Language implementors will be happy because they can keep the language clean as it evolves. Imagine how awesome Java could be today if they took this route.

Re: PHP 5.5

#108
post #68
post #54

Earlier quoted context omitted.

Out of interest, what do you find wrong with the documentation? I've always found it pretty comprehensive and relatively easy to navigate.

Generally very little, but there are things like http://php.net/trader_stoch

To be fair, that is an optional extension and not bundled into PHP by default.

Re: PHP 5.5

#109
post #95

Earlier quoted context omitted.

> Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform. I'm sorry, but given that PHP the platform (forgetting about gripes with the language syntax for a moment) has been used on major projects for years, what more significant progress do you want? Your talking about it as if it needs to prove itself as a viable technology, when clearly this is not th…

^^^^^^ This is the attitude I am talking about. Clearly since it's popular then there is nothing wrong with it. Thats total BS. There are tons of things wrong with it. Yes people do really cool things with the language and the run time, but just because someone using it doesn't make it _good_.

> just because someone using it doesn't make it _good_

Actually, it does. When you give people a large array of choices and they consistently choose the same thing, over and over again, that makes that thing good. Now, it may not be good for exclusively engineering reasons, but it is still nevertheless good.

Re: PHP 5.5

#110

Am I the only one thinking PHP needs more stuff removed rather than added ?

> Am I the only one thinking PHP needs more stuff removed rather than added ?

You can remove things yourself? The PHP codebase is extremely modular. Just compile your own PHP and leave anything you don't want out. Has a wonderful --disable-all flag and then you just add the stuff you need.

Post reply on HN