Emacs!!! XEmacs!!!
Emacs!!! XEmacs!!! Now seriosly kids. My opinion is that none of the modifications that have been discussed actually change the language into something better. Everything that you can do with the proposed modification, you can do without. Sure multiple inheritance makes this easier, but opens up cans of worms only solved in hundreds of development iterations. Sure typing (even optionally) keeps you from shooting yourself in the foot, or at least from hurting yourself too bad while doing it, but it also makes it just a little more difficult to program. Operator overloading makes it so that you don't have to type so much, but adds no functionality to the language (It bugged me too until I learned Java, and what is referred to as operator hell). Case Sensitivity just makes it so that if you can't remember if it's myFunction or MyFunction or myfunction or MYFunction or myFUNCTION (you get the picture) you have to go and look it up before your script will run. I propose that all discussion of adding to or changing the language itself be suspended until such time as it can be demonstrated that PHP can be maintained in and of itself in its current state, and this by use of the following milestones: * A complete regression test suite that is maintained concurrently with the development effort. Each bug that is fixed receives a test case to be checked with make test). A lot of extensions don't even have test suites. And last time I ran make test, the results were so useless and non-representative that I no longer try to run it. (Granted that was a couple of months ago.) * Nightly snapshot builds on the big three: Linux, Windows, and Solaris. I/My company can donate cycles to this task on some pretty nice machines if needed. * Complete core compatibility on all *NIX platforms as well as Windows. If a function cannot be implemented on any given platform, it should be deprecated/removed from the core. Register_Shutdown_function comes to mind. * Average new daily valid bug reports should be less than 10. Average daily open bug reports should be no more than 100. I've got ideas on how to help make this happen, and will release them to any who asks. * Extensions that do not compile and function on every platform should be removed to some non-core location. If it's not portable, then it's not PHP. * Complete documentation on every extension and function and structure and operator and nuance and etc of the PHP core. If and only if all of the above conditions are met can we think about extending/tweaking the language. If we do, any more than has already been done, before we have that solid base, PHP is going to be so top heavy, and so bottom weak that it will collapse. Joseph P.S. <RANT Abstract="Why my company, and as a result, I won't be using PHP anymore, and why this discussion won't change that outcome.">My work with php has come about because we decided that php would be the best platform in which to create a web application. We had experience with mod_perl, CGI, as well as Java, and by far the easiest to use and the quickest to develop in is PHP. The entire application was written procedurally. Only at the very end did I create a class, and that because I didn't feel like passing 6 or 7 parameters when I made a function call and I was being lazy. I never was upset because php didn't have this language "feature" or that OO "nicety". What did get me was the non-portability of the supposedly portable "Scripting Language", but there are open bugs on all of those issues. Nobody's even tried to touch those bugs, but they're open. Now, because of the gotchas we had with the first app, the next web application will be done in C/C++ because it turns out that PHP is not as portable as we were led to believe. This feature or that feature or the other may or may not be available on a given platform. We all have more important things to do: I'd really like the Register_Shutdown_function bug that's been around since the release of 4.1 to be fixed. Then while you're at it, get it working on Windows. That takes precedence over ANY language extensions in my mind, as do all of the open bugs in the bugs database. On a different vein: have you ever tried selling a PHP application to a customer? How about a customer that only has Windows/IIS in house and doesn't feel comfortable about bringing in a *NIX/Apache server in to deploy your product? They care not about whether it is case sensitive, or how Object Oriented it is. They want it to run, run well, and run without crashing. As a general rule, PHP/IIS is experimental at best, but nobody seems to want or to be able to work on it. So we lose sales... I've tried, but failed because I can't understand the Zend engine. What do those lost sales translate to? You guessed it, our next application will not be developed in PHP, and our current app probably will be rewritten in C. And I won't be able to contribute anymore. Such is life. </RANT> > -----Original Message----- > From: brad lafountain [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 2:08 PM > To: Zeev Suraski > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [PHP-DEV] Re: [Zend Engine 2] PHP in the future > > > > --- Zeev Suraski <[EMAIL PROTECTED]> wrote: > > At 08:26 PM 6/6/2002, brad lafountain wrote: > > > > >--- Zeev Suraski <[EMAIL PROTECTED]> wrote: > > > > At 07:01 PM 6/6/2002, brad lafountain wrote: > > > > >Please don't reply to this email saying Use Java... Because php is > > > different > > > > >than java and always will be even with these new features. > > > > > > > > Brad, I beg you, there's nothing anybody can say on this > list that would > > > > lead this to closure. Nothing. I believe that adding the > things you > > > > mentioned does indeed turn PHP into Java, just a messy > Java, Java which > > is > > > > worse at being Java than the real one is, and torn apart > when compared > > > > against it. > > > > > > Why do you think it would be messy. > > > > See Kristian's letters to php-dev. I really don't want to get > into it at > > this point, mental exhaustion :) > > > > > I do believe that making a "fork" or patches for php is a > bad thing. It > > > would > > >lead into a big mess. But at the same time i believe more > strongly that cs > > >is a > > >good thing, types are a good thing and stronger oo support is > a good thing. > > To > > >me these are more important. > > > > I don't think I can add anything about CS that I haven't already > > said. Adding type hints is something that we have talked about in the > > past, and haven't ruled out - we need to think much more about the > > implications. > > This is good to hear. I was totally against types, then i > started thinking > that it would acually be eaiser to use. But i wouldn't want to loose the > floating types too. > > > I believe the OO level we have in ZE2 is the upper limit of > > what a scripting language should have. There's no doubt in my > mind that > > going beyond that is going to complicate the language beyond what our > > average users want. > > Average user.. maybe this is true.. but if you want to target > more advance > developers then you need to go the extra step and do some of the stuff. > > > > > > > There's one thing that is clear to me - there's no way to 'find a > > > > solution', because we don't, at all, agree about the > existence of the > > > > problem. If you believe these features belong in PHP and > that it should > > > > import all (or most) of Java's features, we (and many others) have a > > > > fundamental gap in our perception of what PHP should be, > and how it can > > > > stay competitive. > > > > > > This is exactly true. I really feel that php/zend engine > could be a alot > > > more > > >than you must think it can be. > > > > No, it's not a matter of me settling for little, and you > thinking we can do > > much better. Not at all. While I don't think we can become a > better Java > > than Java, this is not the reason I'm so much against going down this > > path. If that was it, I would have said 'let's give it a try, > what's the > > worse that can happen?' But that's not the case. I believe > that by going > > down that route we're going to ruin PHP where it is already > established as > > one of the most popular web platforms out there, and that's a > price I'm not > > willing to pay. > > But you have one market.. Why not go for another.. You aren't > going to loose > the market that you have. I don't think people will stop using > php for the web > just because it has more options. > > > > > >For the most part the only argument against these is "do we > need it" and "it > > >will make things slower". Maybe somepeople do maybe somepeople > don't but if > > >someone "thinks" they need it then probally others do too, how > much slower > > >will > > >some of these changes make the engine? Maybe not much at all. > True these > > kinda > > >things will make the languge more complicated and some people > don't think > > that > > >php should get complicated but I do, I think that making these > kinda changes > > >can only make php better. > > > > FWIW, I think that performance only plays a second role in such > > decisions. It can indeed rule out certain features if they really slow > > things down without giving a significant benefit, but generally, > > functionality is more important than performance (good > functionality does > > not necessarily mean more features but a good, usable platform, > even if it > > means less features). > > For me, the key questions are "Does that belong in the > language?", i.e., > > would adding this feature to PHP make it a stronger/more > popular/easier to > > use web platform than it already is, and "Is it worth the price (if > > any)?". > > Why settle for just web platform. It has the potental to be > "any" platform. So > here is the question again. > > "Does adding (some feature) to php make it a stronger/more > popular/eaiser to > use development platform than it already is." > > Does adding (more oo features) to php make it a stronger/more > popular/eaiser to > use development language? .... Yes. > > Does adding (types) to php make it a stronger/more popular/eaiser to use > development language? .... Yes. > ( i think this is true for the "web-centric" php too) > > Does adding (CS) to php make it a stronger/more popular/eaiser to use > development language? .... Yes/Maybe. > > For the CS argument, my gut feeling was 'yes' for the first > > question (a long time ago) but when I tried to quantify it, it > occurred to > > me that it doesn't really make it stronger/more popular/easier, > and it was > > a clear 'no' for the second question. In my opinion, we should ask > > ourselves these questions about every new language-level feature. Of > > course, even if we agree on the questions, it doesn't mean we'll agree > > about the answers - but it would at least be a good start, and a good > > change from "Why not add it?", which many people use today. > > > - Brad > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
