# PHP is not ... - Thread: https://externals.io/message/64857 - Original archive: https://news-web.php.net/php.internals/64857 - Started by Lester Caine on 2013-01-11T09:44:23+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64857 — Lester Caine — 2013-01-11T09:44:23+00:00 URL: https://externals.io/message/64857#64857 Some of you will have heard this before, but please bare with me ... A number of years ago I needed a new infrastructure to produce 'web based' versions of the windows client code I've been writing since window 3.1 days. I'd been using C++ for many years and still have to support that code. C# and other esoteric 'modern' offerings were being pushed at that time. Some have taken off and some have proven less popular. I started playing with PHP just before PHP5 became RC stage and was very pleased with what I found. An OO 'style' of working that allowed me to escape the straight jacket that the BCB6 object methods enforced and easy learning curve from what I was used to. Since that time e_strict rules have been 'applied' and while I accept some of the logic of those rules, having to create multiple functions to get 'around' the static/object restrictions was starting to create the bloat I'd lost initially. Currently being able to check if an array or a simple variable has been passed gets around the problems I had with BCB6 needing to create separate function wrappers for each parameter type, so discussions on 'improving' this area irritate. Being able to access object variables directly was a big plus so all of the 'magic' to hide them again is annoying. Debugging library code I've been using for years is becoming more and more difficult due to the 'extra' material that is appearing, and I have no doubt that adding 'annotations' into that code will further reduce productivity :( *I* have no control over that, it will happen simply because that seems to be the way people think PHP should go? 'You don't have to use them' is rolled out all the time, but as others have said, unless you don't use ANY third party code that is simply not practical! If I'd wanted C# 10 years ago I could have used it. I found PHP was perfect but it's becoming a case nowadays when I seriously have to consider how I go forward. I have to use Python and Ruby with all of their idiosyncrasies along with fixing bugs in Java to keep my development tools working, so all this talk about 'modernising' PHP is like a sword in the side. Surely I'm not alone in wanting to keep PHP as the simply development platform it had always been and 'improving' things like unicode support and performance? I keep thinking that 'e_simple' is the way to go and disable all of the 'complicated' stuff and - yes - get back to the good old days ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #64858 — Thomas Hruska — 2013-01-11T10:35:55+00:00 URL: https://externals.io/message/64857#64858 · In reply to: #64857 > Some of you will have heard this before, but please bare with me ... The folks on this list don't need to see you naked. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you might find useful. http://cubiclesoft.com/ --- ## #64859 — Arvids Godjuks — 2013-01-11T12:06:00+00:00 URL: https://externals.io/message/64857#64859 · In reply to: #64858 I have to agree with Lester. It seems that there is a conspiracy to push annotations into PHP :D No, really, it's like goons decided that PHP needs annotations no matter what and just flooded the mailing list. I think: "The line must be drawn here, this far, no further!" © Star Trek Before adding more major stuff we should cope with what was already added and get it into shape. Traits are getting a rewrite for the 5.5 release and APC can't catch up because of the traits. This is the first big problem that needs to be solved. Unicode is the second big problem. As far as I know there was some work done on mb_string like enabling func_overload by default, but there are functions missing that are in standard string extension. Just continue on course and get more people involved. Maybe make a roadmap and try to stick with it. 3rd problem is PDO. It lags behind for years and as far as I know from the words of Perrie, no one is willing to touch it and it's a mess. I will not even start on the fact that it lacks tons of functionality and is extremely limiting when you start to do some serious stuff. The fact that virtually every framework bases it's DB layer on the PDO makes it even worse - a fast comparison between PDO and mysqli shows how limiting the PDO is. Just an example, mysqli has mysqli_ping. You can't do that in PDO, so I had to send a query "SELECT `NOW()`" every 10-15 seconds to the MySQL server to keep the connection alive. Because when PDO looses connection, it gives you an error and you can't just reconnect and continue. Oh, the PHP function API issue, like array vs string. Huge amount of improvements can be done here. This is just what gets into mind and I stumble upon regularly. Maybe these problems should be addressed first before adding more stuff? Arvids. --- ## #64860 — Florin Razvan Patan — 2013-01-11T12:25:31+00:00 URL: https://externals.io/message/64857#64860 · In reply to: #64859 Hi Arvids, This is exactly what I've stated yesterday here, you can read it at http://news.php.net/php.internals/64820 but I've yet to receive an answer for it. The problem is that someone will actually need to implement the whole thing again, in C, again, and it's going to be painful (again). I can only say that I'm really sorry that I don't know C in order to be able to contribute. This is indeed a sensible subject and I wouldn't want to be hated by the current developers / contributors but like I've said, at some point it must be addressed. Best regards, Florin ---- Florin Patan / @dlsniper On Fri, Jan 11, 2013 at 2:06 PM, Arvids Godjuks wrote: > > I have to agree with Lester. > > It seems that there is a conspiracy to push annotations into PHP :D No, > really, it's like goons decided that PHP needs annotations no matter what > and just flooded the mailing list. > I think: "The line must be drawn here, this far, no further!" © Star Trek > Before adding more major stuff we should cope with what was already added > and get it into shape. Traits are getting a rewrite for the 5.5 release > and > APC can't catch up because of the traits. This is the first big problem > that needs to be solved. > > Unicode is the second big problem. As far as I know there was some work > done on mb_string like enabling func_overload by default, but there are > functions missing that are in standard string extension. Just continue on > course and get more people involved. Maybe make a roadmap and try to stick > with it. > > 3rd problem is PDO. It lags behind for years and as far as I know from the > words of Perrie, no one is willing to touch it and it's a mess. I will not > even start on the fact that it lacks tons of functionality and > is extremely limiting when you start to do some serious stuff. The fact > that virtually every framework bases it's DB layer on the PDO makes it > even > worse - a fast comparison between PDO and mysqli shows how limiting the > PDO > is. > Just an example, mysqli has mysqli_ping. You can't do that in PDO, so I > had > to send a query "SELECT `NOW()`" every 10-15 seconds to the MySQL server to > keep the connection alive. Because when PDO looses connection, it gives > you > an error and you can't just reconnect and continue. > > Oh, the PHP function API issue, like array vs string. Huge amount of > improvements can be done here. > > This is just what gets into mind and I stumble upon regularly. Maybe these > problems should be addressed first before adding more stuff? > > Arvids. --- ## #64862 — Clint Priest — 2013-01-11T15:22:57+00:00 URL: https://externals.io/message/64857#64862 · In reply to: #64860 I can't disagree with some of your sentiments, that new things are being developed while there are some "old things" that are incomplete or in dis-repair. Unfortunately, PHP being developed as it is, there are only so many people able to work on the core. My own story with php-core was like this. I personally started using accessors in other languages long ago and I was forced to use __get() in php in order to have any sort of lazy loading or dynamic calculations. My own large project has grown to the point where there are a few __gets() that are just ridiculous in size and that's when I decided to check out if PHP was ever going to get accessors so that I could properly compartmentalize my code. I found that Dennis had written an RFC several years before but never had the time (or possibly the ability, not sure) to write it. I had started with C and C++ some 20 years ago, but hadn't written in it in 8 or 9 years. I had talked with Dennis about the original proposal and he helped me a bit w/ the internals list/ideas/processes at the beginning, but really it was up to me to get it done. So I stepped up and made it happen, it's been a long road, the worst of which has been both the RFC process (everyone has a voice, nobody has authority) and the lack of help for the tough problems I encountered. My point is there are only so many people that work on the core and if they are not interested in improving it in the ways that you are, then you need to step up and do it yourself. Learn C if you must, it has some sharp edges but it's not an alien language. It's nice to sit and point at all the problems, but if you can't fix them yourself and you can't convince someone who can to do it, then maybe it's time to step up and learn how to do it yourself, then everyone can benefit; that's what I'm doing. -Clint > Hi Arvids, > > > This is exactly what I've stated yesterday here, you can read it > at http://news.php.net/php.internals/64820 but I've yet to receive > an answer for it. > > The problem is that someone will actually need to implement the > whole thing again, in C, again, and it's going to be painful (again). > > I can only say that I'm really sorry that I don't know C in order to > be able to contribute. > > This is indeed a sensible subject and I wouldn't want to be hated > by the current developers / contributors but like I've said, at some > point it must be addressed. > > > > Best regards, > Florin > ---- > Florin Patan / @dlsniper > > > > > On Fri, Jan 11, 2013 at 2:06 PM, Arvids Godjuks > wrote: > > […] -- -Clint