Slashdot Mirror
PHP 5 Beta 1
Sterling Hughes writes "The PHP development community is proud to announce the release of PHP 5 Beta 1. Downloads are available in both source and binary form (for Windows users). A full list of changes is available in the ChangeLog. Some of the new features include much improved OO support, completely revamped XML support, and the default inclusion of SQLite."
I love the slightly condescending (in binary form) for Windows users ! Says it all really.
Top Most Bizarre/Disturbing Error Messages
That's right, now you can say class { @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{q *=2) +=$f=!fork;map{$P=$P[$f^ord[ P.]/&&
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print }
Take a look at the OO changes page. The syntax seems to be converging with Java. I find this amusing in some ways.
The PHP people need to provide ways that people can upgrade the versions of PHP on their system such that they can be reasonably sure that existing users aren't suddenly going to find their sites don't work.
And what about apache 2? Up until now, they recommend that users stick with apache 1 if they want to use PHP as a module.
but ASP/Mircosoft was faster then the guys from Zend. But PHP is way cooler and you don't need IIS.
Grundgesetz * 23. Mai 1949 - 30. November 2007 - http://www.vorratsdatenspeicherung.de/
I just want to know when they're going to add OO support to as.
It's still lumped into a great big inconsistent namespace
... pool database connections maybe? no, mysql_pconnect() doesn't count. Oh, and what's with this SQLite thing? had a bit of a fallout with the MySQL team?) ... because that kinda defeats the point of PHP anyway.
..... (x47) really want to like Python, but it's not re-entrant and has a big interpreter which makes its threading capabilities into nothing more than a silly joke (and last I checked, efforts to rectify the situation died back in, what, 1997?), so yeah I admit I use PHP for quite a few web devel jobs. But just because everything else sucks more, doesn't mean PHP doesn't suck any less.
It's still made by a for-profit company who hobble the product in order to not cut into their profit margins too much (Hello? Zend Cache? Optimiser? Compiler? Everything's free in PHP-Land, for a small fee in PHP-Land...)
I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace (as opposed to one URL -- how very un-spider-friendly. Most choke on a ? in a URL and rightly so) and remain persistent (allowing you to do funky stuff like
But come on. Fellas. PHP: Hypertext Preprocessor is the name. Not PHP: Application Server. If those first two issues were fixed it might actually make a seriously powerful hypertext preprocessor. That's something it's reasonably good at. But at the moment it's some sort of bastard preprocessing language run amok that people use to write whole web applications with and other stuff Nature never intended. Perl's got an awful syntax and a total lack of convention (and mod_perl is really byzantine), and I really really really really
I'm not even sure what my point is anymore. But, I think what I was trying to say was this isn't much. Same stuff is true of PHP as has always been true of it... wake me up when they get round to PHP6. An earlier rant I made comparing Perl to PHP (I think I preferred Perl back then) is here. The extended comment history is pretty much the only reason I got a subscription and to be fair I think it's worth the money.
just glad they have so many mirrors. I was worried the /. effect would have kept me from getting it
YOU SUCK BALLS!
God damn!
I'm half-way through re-writing our website to remove our dependance on the depreciated register_global_variables stuff which I learned to live with and then was told was a stupid idea.
I'm hoping they don't break too many other things 'cause being a php beginner, the whole process is a bit of a nightmare.
I have always been very annoyed not having destructors in PHP. PHP5 includes destructors, along with public/private class members. I can't wait for this to be released as a stable version.
MySQL isn't bundled with it, but you can easily add it yourself when compiling.
Compiling?
Compiling PHP for Windows requires the Microsoft Visual C++ compiler version 6.0 or later.
The Microsoft Visual C++ optimizing compiler version 6.0 or later is available only from Microsoft as part of Microsoft Visual Studio .NET, which costs $1,079 for one non-academic seat. (Microsoft no longer sells a Visual C++ optimizing compiler separately.)
Some people are bound to bring up the $109 Microsoft Visual C++ Learning Edition, but 1. the EULA attached to its library probably does not permit distribution of generated binaries nor public performance (i.e. use on a public web site) of generated binaries, and 2. because it does not have an optimizer, the speed of generated binaries is closer to that of an interpreted program than to that of a compiled program.
If I had any spare time, I'd fix this by porting the build to MinGW.
Will I retire or break 10K?
This looks like a really cool release - the Get/Set methods would be ideal for binding a class to a database. e.g.
$user->name = "joebloggs";
could automagically update the tables for you.
MikeJ
Mikesroom.org
what's so difficult about using your own mysql installation?
How do I tell binary PHP to use the installed binary MySQL?
Please read this comment before replying with such an answer along the lines of "compile it yourself".
Will I retire or break 10K?
So how long until we get the final version?
...).
I'm currently developing a PHP project with lots of OO code and it's about as plesant as removing your eyes with a rusty spoon (some control structures implicitly copy objects, they don't know how to return references, you can't write $a->getB()->doSth();
Improved OO support in PHP5 would be really nice riht now.
if you have a huge site, doing that is a quite a tedious job. If you want a quick fix. Do the following for all of the variable arrays. -- foreach( $HTTP_GET_VARS as $key => $value ) { $$key = $value; } -- As I said, just do that for POST, COOKIE, SESSION etc. Also, you can change the order so that POST has more weight than get (POST variables overwrite GET variables.) by simply doing the POST after the GET :)
Do this in one file and include it in the top of every page. (If you have a config file, do it there, so you don't have to go and include it throughout your entire site)
This is an easy fix for doing what you want.
-goat
I'm a PHP programmer and I've begun to recognize a pattern in software: when will we see the end?
Truly, what more can you add to PHP? Why do most software packages continue to add features without actualy providing a subjective goal to strive for?
For example, in the world of Microsoft(R) Windows we see the same operating system have plastered above it "Where do you want to go tomorrow" and above all "n% faster than previous, more stable, etc." When will the goal of a products feature-list finally be met?
I know Perl5 accomplished its goals, and then they had an {ap-if-in-ee} to add the RegEx in yet another release of Perl titled Perl6. When will they ever make a product that has a goal? I don't call this competition...I call it beating a dead horse from its grave, like how Intel puts rocket boosters on its crumy brick CPU architecture (Pentium Pro) and adds some more features.
Look at netBSD; it isn't dying, it's still working on its number-one goal: security.
Linux is the same way; it stated from an original design and now is being extended. Am I sounding like I expect a new feature to be a new product? I don't think so... GNU/HURD, of which I know many people are skeptics unto, is builind upon its goals of being a Micro Kernel and add some. What if Linux all-of-a-sudden wanted to become a Micro Kernel? What if Microsoft(R) Windows(TM) all-of-a-sudden wanted to become a Micro Kernel?
The software names, after huge changes to extend their capabilites, are becoming misleading! If you take out a RedHat Linux 5.2 system and compare it with RedHat Linux 8.x, you can't say they are both similar Linux; they are completly different! Sure, it's like comparing apples with oranges on the old and new RedHat, but Kernel-wise the latest Linux Kernel may look completly different and have completly different goals and features than what was hoped for in the verry early Linux kernels. Shouldn't to cause less confusion and more inspiration, they leave the Linux name behind with the old design and all the new stuff that would completly change Linux's software (mechanical?) appearance become known as the new project Herring(TM). I anticipate most of you will reply with "That's why we have VERSION NUMBERS", but hey? You're missing the point.
Microsoft(R)'s Windows(TM) name isn't describing the project's code name, yet the product's retail names are somthing like 95, 98, NT, 2000, XP. Well, it is honest to say that the NT and 2000 products are similar, 95 and 98 products are similar, and the XP product isn't quite similar to 95 and 98 and 2000, but then there was the fiasco that all the 9x users went out to buy product Windows(TM) 2000 and found they had been tricked by Microsoft that 2000 would be like a 95 or 98. Anyone see my point?
As for PHP, and perhaps Perl... Does anyone think they should continue calling those products by their initial names AFTER the programming syntax and methodology becomes completly different or non-compatible than they were first designed?
I'm looking forward to some intelligent answers. Thanks and I'll be a PHP and Perl programmer for a long time to come. d:-)
If there was some way that you could allow the user to have multiple PHP versions all being used as Apache modules where the user could select the one they want using their .htaccess file, that would be a possible solution.
Of course, the real solution is for the PHP development team to take the issue of backward-compatability more seriously then they clearly do at the moment.
On Sat, 28 Jun 2003, Marc Richards wrote:
l s&article=%3CPine.LNX.4.56.0306272256280.6461%40th inkpad.lerdorf.com%3E
> I apologies if this is the wrong place for asking. Is non-experimental
> Apache2 support planned for PHP 5?
Nope. Until someone sits down and goes through every 3rd-party library that can be linked into PHP on every platform and identifies whether or not they are threadsafe and under which conditions they remain threadsafe, using PHP in a threaded web server on UNIX is going to remain experimental.
You can of course stick with non-threaded prefork mode, in which case you basically have Apache-1.3.x. Nobody so far have been motivated to test Apache2-prefork+PHP extensively, so even that combination is going to remain experimental.
The basic problem here is that the average UNIX library has not been written with thread safety in mind. You can write very good specific threaded programs on UNIX, but it is extremely difficult to write something which can potentially link in hundreds of random libraries and expect them to all be threadsafe.
-Rasmus
http://news.php.net/article.php?group=php.interna
John Kerry is a Joke!
Please mod this up. It is absolutely freakin hilarious (because this is exactly what people will say)
sonova, selected something wrong. ;)
:)
---
if you have a huge site, doing that is a quite a tedious job.
If you want a quick fix. Do the following for all of the variable arrays.
--
foreach( $HTTP_GET_VARS as $key => $value )
{
$$key = $value;
}
--
As I said, just do that for POST, COOKIE, SESSION etc. Also, you can change the order so that POST has more weight than get (POST variables overwrite GET variables.) by simply doing the POST after the GET
Do this in one file and include it in the top of every page. (If you have a config file, do it there, so you don't have to go and include it throughout your entire site)
This is an easy fix for doing what you want.
-goat
The will be an interesting battle. JSP and PHP are now broadly identical in syntax and OO implementation. Who'll win? PHP is OS, but JSP has a huge amount of support from corporations.
I'm betting on JSP
((lambda x ((x))) (lambda x ((x))))
Wow, I read the "OO enhancements" and I was amazed they they would call it "OO enhancements" vs "adding OO capability". I've never used PHP, so I have no real basis for this flamesque statement, but: How they heck can you call a modern language OO without abstract methods, protected field/method access, pointers/references/identifiers/etc, overloading, statics, and all that? I mean really, it sounds like the only real "OO" capability older versions had was calling blocks of code a class, and very broken (read: nearly useless) inheritence.
Without the above it's impossible (or at least a total pain in the arse) to accomplish most of the "cool" stuff in OO such as polymorphism (needs method overriding, and modular design with inheritence (if you don't have "protected" access, you can't take advantage of inheritence without breaking modularity).
As a side note: holy sh*t, I can't believe earlier versions did call by value with OBJECTS! Talk about a poor design decision.
Just my rant for the day...
Which speed? All the comparisons between PHP, ASP, JSP... say that PHP is the winner. For example here.
;->
PHP5: Ready For The Enterprise? --> I think PHP5 will be ready after the first round of bugfixing of course
Grundgesetz * 23. Mai 1949 - 30. November 2007 - http://www.vorratsdatenspeicherung.de/
Can't we say the same for ASP? It's compiled, has been for years.
scott
um..
O KIE);
extract($_POST);
extract($_GET);
extract($_CO
?
bananas like monkeys.
Advice: .dll (Depending on which webserver you're using - php4apache.dll for Apache, php4isapi.dll for IIS)
.dll's to run PHP as an integrated CLI SAPI? Performance! This method was officially documented as a stable feature in the December 2002 build of PHP.
The default method of configuring PHP is with the CGI SAPI module (i.e., php.exe); A much better choice (imo) is to configure the CLI SAPI module - all you have to do is build the CLI SAPI
(Also, many websites refer to the two config methods as CGI and SAPI; This is not really correct since CGI *is* a server API. What they really mean is CGI SAPI & CLI SAPI)
So, why go through the trouble to compile
Ok, so you're still asking WHO CARES??? Here's why you care: When you use the '.dll' method (CLI SAPI), much more of the processing work is passed onto the kernel resulting in fewer system calls. A LOT of people complain that PHP is slow & inefficient compared to other webservers, but oftentimes, these people haven't tried the CLI SAPI of PHP! Their point of reference is an ISAPI webserver (IIS) & they are comparing apples to oranges.
To find out what SAPI you're using, just execute php -v
Observation:
PHP adds new functions & deprecates other functions waaaay too often; No wonder people are leery of upgrading!
I have always wanted PHP to have an XSLT based transformation pipeline, similar to what Apache Cocoon has. I would like to be able to write source documents in XML, arbitrarily transform XML into HTML and PHP, interpret the PHP, possibly transform again and finally output the results. I know I could build this top-down from within a single PHP document, but I'd like this pipeline to be a part of the mod_php distribution, with the .XML file extension mapped to the pipeline processor.
Anyone wanna help me build it?
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
Hi,
I just installed php5 and installed
turck cache, too. It works!
e.g. phpmyadmin works perfect
But apache benchmark (ab) shows a 15%
speed-decrease in comparison to php4.3.3
> No Java, no JSP man. Simply use PHP for web development. > Forget Java man and go to PHP! > > PHP is 4 times faster than Java technology 'JSP' (Java server > pages). Substantiate that statement. What benchmark, what workload, etc. > This tallies because compiled "C" program is 4 times faster than > Java. PHP scripts are re-interpreted, at runtime, *for every page hit*. They're not C. > Moreover, PHP is getting the object oriented features of Java > language. Yeah, *finally*. Partially. This is the 1st go. Java was designed from the start to be OO, it isn't hobbled on like with PHP. > The real usefulness of Java is 'Java applets' which run on > client browsers but on the server side you simply use PHP. Substantiate. > PHP is a very lightening fast object oriented scripting > language. PHP is 100% written in "C" and there is no virtual > machine as in Java. Nothing can beat "C" language ("C" is a > language which never dies!!) Jeez, moron. What do you think the JVM is written in? > (Java is just another language. The PHP project needs millions > of Java programmers who can add the Java's language features > like inner classes, static, private, protected and others to > PHP. PHP already has some of java' features). > Java programmers will really "LOVE" PHP as PHP class is > identical to Java's class keyword. I use Java and PHP, and I *loathe* PHP. It's single redeeming feature is that it's everywhere. For the rest, it's a language with crappy library support, that actively emcourages mixing the presentation and business layer. > Read the benchmars of Java JSP and PHP. PHP tops in the speed!! Substantiate.
oh sure, make me look like a dumbass.
Thanks, didn't know that one.
> No Java, no JSP man. Simply use PHP for web development.
> Forget Java man and go to PHP!
>
> PHP is 4 times faster than Java technology 'JSP' (Java server
> pages).
Substantiate that statement. What benchmark, what workload, etc.
> This tallies because compiled "C" program is 4 times faster than
> Java.
PHP scripts are re-interpreted, at runtime, *for every page hit*.
They're not C.
> Moreover, PHP is getting the object oriented features of Java
> language.
Yeah, *finally*. Partially. This is the 1st go. Java was designed from
the start to be OO, it isn't hobbled on like with PHP.
> The real usefulness of Java is 'Java applets' which run on
> client browsers but on the server side you simply use PHP.
Substantiate.
> PHP is a very lightening fast object oriented scripting
> language. PHP is 100% written in "C" and there is no virtual
> machine as in Java. Nothing can beat "C" language ("C" is a
> language which never dies!!)
Jeez, moron. What do you think the JVM is written in?
> (Java is just another language. The PHP project needs millions
> of Java programmers who can add the Java's language features
> like inner classes, static, private, protected and others to
> PHP. PHP already has some of java' features).
> Java programmers will really "LOVE" PHP as PHP class is
> identical to Java's class keyword.
I use Java and PHP, and I *loathe* PHP. It's single redeeming feature
is that it's everywhere. For the rest, it's a language with crappy
library support, that actively emcourages mixing the presentation and
business layer.
> Read the benchmars of Java JSP and PHP. PHP tops in the speed!!
Substantiate.
Problem solved.
Its better software engineering wise to use layer with ODBC or something similiar to access your database. Changes to your database will not require whole rewrites. Also you can host the database on a different server other then your web one.
I consider myself an amuture database programmer so feel free to correct me if I am wrong regarding something like ODBC to connect to a remote server. I think Oracle has some proprietary redirector/protocal similiar to ODBC but I have never used it and can not comment.
Anyway its not a problem and its good on your resume to learn general sql commands and switch between Sybase, postgreSQL, and MYsql rather then hardcode to a specific database.
I also recommend Interbase if your looking for a great way to learn ANSI sql via odbc. Its free from Borland. PostgreSQL looks cool but it has mediocre WIndows support via cygwin.
http://saveie6.com/
Uh, none of those links work, however here is a *recent* comparison of JSP and PHP using several different containers for JSP and PHP. It seems that the server setup has a great deal to do with the speed of the application (duh).
It's interesting that people like to make comparisons to JSP and ASP all the time but don't remark on what platform they run on. Obviously JSP running on tomcat/apache through with mod_jk will be slower than with just plain Resin.
And open should note that a statement like ' Kiss and say goodbye to Java language!!' almost sounds like a troll, when you consider Java is used for a great deal more than web applications, indeed the servlet functionality that JSP relies on is a *very* small portion of the overall tools that Java supplies to developers.
But whatever, use the right tool for the job and try to remember it's technology, not religion. The more options the better IMO.....
1400x1250 in a 640x480 world...
And it works. I have not found any bug yet.
Even my old configure-Script for
compilation of php 4.3.3 is working to
compile 5.0.0b, too!
Turck mmcache - a php-accelerator, encoder
and optimizer is working, too!
A benchmark made by completely unbiased people. Whoops, I lied.
The raw speeds of execution between JSP and PHP may be similar (though I suspect that JSP ends up being much faster once the JIT has kicked in and optimized it, after a few executions). Additionally, there are many different JSP runners (Tomcat is only the reference implementation) and the performance between them can be very large (I recommend the JSP runner by Caucho for performance-critical systems. Besides this, PHP and JSP have a very, very large difference between them:
PHP is usually run as a apache mod or sometimes, as a cgi. Because of this, it cannot store session state or cache inside of its process (since the process is either apache httpd, or the cgi, which terminates at the end of a page run). To get around this, any session variables get serialized and stored to disk at the end of each run, then un-serialized at the beginning of the request. This also means you can have no application-level caches of database information, since there is no place to put these. This is fine for small stateful sites or large stateless sites, but for any serious, large web application that has to maintain a lot of state, this ends up being a big performance disadvantage.
JSP, on the other hand, is run from a servlet runner in a persistent process outside of the apache process. At the beginning of the request httpd makes a socket connection (usually a local unix socket, very fast) to the servlet runner and sends the request there. This is slightly more overhead than everything running in-process, but gives you the huge advantage of being able to cache whatever data you wish to inside the servlet runner's process. This means database lookups can be cached, sessions don't need to be stored in disk, timers for maintenance functions can be set, all within the servlet runner's process. This is great for large, complicated web applications but obviously not great for small, stateless systems, since it requires the overhead of a running JVM at all times you want the application to be available.
Two different types of systems, two different purposes. I happen to use both in my professional web development, but use only java servlets and JSP for serious projects.
You don't have to recompile all of PHP to get PDF support. Depending on distros, there are a number of precompiled .so extensions that you can use dl() on to load dynamically, without recompiling PHP. You may need to walk through recompiling *part* of PHP to make the specific module from source, but you don't need to recompile the whole thing and reploy it, just enable it because it's an .so file.
creation science book
Windows users don't have time to go fucking around compiling everything they want to actually use. Linux users apparently revel in it.
Or they can go get the binaries for their specific distribution, which are conveniently linked to from the downloads page... oh wait... they're not... not even for the stable/released versions....
Yes, it does say it all. Windows users can get their work done. Linux users can spend their life RTFM.
Considering that I've been a Linux/Apache/MySQL/PHP developer since they each were available, it's just disgusting that they're making it harder to support MySQL at a time when LAMP is a recognized contender against Microsoft. I am not going to fscking rebuild a bunch of sites' dbs and recode MySQL-specific PHP code just because the GPL gives these guys a rash. Certainly when PHP was under Rasmus's authorship and control, he was never this sort of jerk.
I'm not saying I can't take the trouble to link in MySQL libraries, just that there's no good excuse for the PHP folks to make me - and thousands of others - go to this trouble. They could, if nothing else, distribute their nonGPL PHP, plus a GPL kit that adds MySQL support, if they're too scared that the GPL will give them cooties.
"with their freedom lost all virtue lose" - Milton
Yes yes.. To sooth all the scalp scratching surrounding PHP and FREE (quality) cacheing and encoding look no futher than
.001 slower than zend (faster than PHP Accelerator) and it FREE! Did I mention it works with Zend Optimizer , Zend Encoder and it can also Encode (protect) PHP files?
MMcache - http://www.turcksoft.com/en/e_mmc.htm
It's only a split second
I'm too damn good to you people! ; )
PS: PHP makes programming fun again. Thats why people like to use it. Simple really.
and PECL is "The PHP Extension Code Library (PECL)".
creation science book
You are so right!
/.er for your help in making me to realize the errors of my ways.
I don't know why I ever thought that persistant state across a cluster of machines was a good idea. Why didn't I just send queries to the database every single page load?
MVC is overrated. Struts and Webwork are toys so that developers don't have to do mindless work like design a web page. Taglibs are no match for cut'n'paste of PHP code.
JDBC's gaurantee of levels of ANSI SQL compliance is stupid, who would want to use a database other than MySQL? Hibernate and JDO are silly; why would anyone want to map objects directly to rows in a database.
JavaMail API is no match for PHP's mail sending and recieving. Who would want to support both IMAP and POP3 without writing their own code to handle each?
I can't believe I've been using JSP and Servlets so long that I thought they were fast. No one ever uses many function calls to warrant actually including them in wholistic benchmarks. I know I've never developed anything more complicated than select * or hello world. I'm glad most of these benchmarks use BlackDown as their JRE, because we know a good JIT isn't worth the effort. Though I don't use anything complicated in my scripts, the speed of floating-point math that isn't IEEE compliant is so important, I would have a special section for it in my benchmark.
I can see all those enterprise level companies that link their inventory, customer relation, warrenty information, and tech support altogether crying because they should have used Personal HomePage for their corperate infrastructure.
Well, I'm going to go burn all my JSP books now that I can sleep better knowing they aren't useful. All those wonderful 404 links really clued me in to my idiocy. Thank you brave
Karma Clown
You are brilliant. I thought I was the only human being on the planet who noticed (much less GAVE A RAT'S PATOOTIE) that PHP was now controlled by a for-profit entity. Email me some time (jb AT twu DOT net) and I'll gladly host your Web site forever. You rule.
Honey, I shrunk the Cygwin
http://www.faqts.com/knowledge_base/view.phtml/aid /22154
Peace
Also you can host the database on a different server other then your web one.
n ec t.php
Not a problem with most databases except for MS Access...
http://www.php.net/manual/en/function.mysql-con
mysql_connect
(PHP 3, PHP 4 )
mysql_connect -- Open a connection to a MySQL Server
Description
resource mysql_connect ( [string server [, string username [, string password [, bool new_link [, int client_flags]]]]])
Well, with PHP yes, all of the DB function calls are prefixed with the database type, so either you write your own abstraction layer, or you do a global search and replace. Or you could use perl where the DB type is only mentioned in the connect function, only one place to change for each app.
Spencer Ogden
I mean considering Windows users already have access to ASP.NET and SQL Server, why would they waste their time with PHP and mySQL?
He said database, not MS Access.
Access is a toy, suitable only for middle managers who think they are too good for Excel.
Yeugh!
No, no, you're meant to be posting to the irony thread!
Yours Sincerely, Michael.
NT
Actually, I think you mean sarcasm, but it is pretty ironic that less people know the difference now that /. had an article on it. I'm glad I don't read any of the articles!
Karma Clown
Take it all back.
I looked at the manual and only found this.
That is not good. This module needs some work and does not look too mature.
This blows for people like myself stuck on Windows/Mysql bigtime. I also hate using DB specific function calls. ITs poor programming in my opinion that leads to more work later on and vendor lock in.
http://saveie6.com/
though I liked this language a lot better when it was called Java and had organized class libraries...
on the other hand PHP is good for quickies. Smarty is pretty handy too though I've grown rather attached to the simplicity of Perl's HTML::Template (CGI::XMLApplication is another one to keep your eye on).
It's great to have choice, whatever the case.........
Not to be a troll but I thought this would be an excellent opportunity to mention Mason for those of you who use PHP but are more proficient in Perl. All my previous web development has been performed in PHP, however, recently I've started to use Mason/Perl.
Mason/Perl provides similar functionality as PHP using in-line constructs such as "<%perl> $perl = goes($here); </%perl>", "% $perl = goes($here);", "<% $variable %>", and "<& function.html &>". Its modularity has allowed me to create a dynamic website coded completely in Perl! It provides all the power of Perl, combined with the convenience of in-line PHP, and adds a new level of object-oriented modularity.
Not that I didn't enjoy PHP, it's just that I always felt like I was coding with one hand tied behind my back. If you like Perl, check out Mason.
Michael.
Linux : Mac
I don't know whether to flame you or thank you for leaving "hl=no" in that URL. I guess I should thank you, since figuring out why Google was assuming I was Norwegian was very instructive!
PHP 5 isn't really documented in the PHP 5 manual yet as there are still a few features on the move, and new features to come, but here's a list of PHP 5 related articles and presentations:
Faq: Where can I get more information about PHP5?
Enjoy!
Yes my friend, you have been caught feeding the trolls.
I am TheRaven on Soylent News
You don't have to move to PHP 5, if an earlier version does the job the way you want it to.
Just like for any other piece of software: if you don't see something new worth any potential upgrade fee or hassle in converting your stuff, don't do it.
Get off my launchpad!
Hey HeadDown. You're right to take the guy to task, s/he made some crazy comments. But I can at least partially substantiate speed issues. Back in 2000, I worked with Sabeer Bhatia (the Hotmail guy) on a startup called Arzoo. Our product (a Web site similar to epinions) was almost 100% Java, except for a bit of Perl for screen-scraping and searches. But anyway, it was slow -- first with Tomcat, then with JRun. At one point, we gave a private preview to 1,000 journalists. They didn't even visit the site all at once, they trickled in over the course of 3 days or so. Just that was enough to hammer the site. We ended up running cron jobs that would reboot the farm, round-robin, just to solve memory issues and instability.
Now, you can say, well, that was 2000! Try it now! OK. At SST, we have a team that is using Tomcat now. Although the instability is gone, the speed is still an issue -- they have wait screens as you click through the app. My team is working with PHP, and has no wait screens, and no need for them (with 1 exception). Our pages are actually more computationally stressful than the Java stuff, yet PHP is delivering the result to the browser faster.
As a final point, you might suggest that the teams I've worked with do not understand Java or how to run it well. It's no skin off my back if you make that argument -- it's not me doing this stuff, so no blow to my ego. But I think working with 2 different teams over the course of 3 years says something. Perhaps, at the very least, if Java really can handle a bigger load, it is so difficult to tune that mere mortals would do better with PHP.
My Greasemonkey scripts for Digg &
Both will win.
The latest news from Sun is that J2EE 1.5 will support scripting languages. And the reference implementation will be done in PHP.
If you don't believe, check some of the news site reporting on JavaOne 2003.
I am a PHP programmer and have programmed some Java some years ago. I do PHP almost exclusively now, but I always liked Java and I am thinking that maybe JSPs may be worth a look.
So although I currently don't feel an urgent need to switch and will definitely have to maintain PHP code for the rest of my life (probably ;-), I'd like to play a bit with JSP, especially because Java is so universal (runs on servers, browsers, desktops and embedded systems)
What tools do you use/recommend? (What servlet engine, just an editor or a RAD-tool?)
The way I see it, a servlet engine is more or less a JVM that puts the (standard?)output of a Java program to the webserver/browser, is that correct? (A short browse on the Apache Tomcat page could not answer that very simple question)
Thanks a lot for answering that questions.
I've been using PHP since the 3.0 days and always loved it's speed in development for small dynamic sites. There is truly nothing simpler (IMO) for small sites. Why on earth did PHP ever become so popular as compared to Perl/CGI? It was the simplicity.
Most people accepted the changes from PHP3 to PHP4 without complaining as PHP4 brought simple session support and other needed features. Thousands of developers wrote scripts for small pages and uses, and those scripts got placed on help sites etc all across the web.
The changes above 4.06 where register_globals got turned off by default and -from a simple beginners point of view- to 4.2 where a stunning array of new arrays were added for sessions, post and get variables. Those things broke almost everybodies scripts, and all those thousands of scripts across the web no longer worked as is. Due to this a lot of ISP's no longer upgraded regularly.
At the same time PHP started jumping on the "web application" gravy train, something for which PHP with it's awkward OO support (no automatic calling of parent constructors etc), lack of stateful session support etc was not designed to do. The makers of Zend decided to go the whole hog and redo OO support, add hundreds of seldom used features but ignore problems with backward compatibility and language simplicity.
Congratulations. Now we have a language that is slowly matching JSP in complexity (as all the 1337 "application developers are saying"), is nowhere nearly as well integrated in in true web applications as JSP is (great, it can support Java classes, how many will simply use Java then?) and is leaving the roots of it's enormous success behind.
Take a lesson from Perl's "failure" in web site popularity. Don't keep on adding features for the love of it.
I'm using definition 1a of irony.
Yours Sincerely, Michael.
I liked it best when Vlad had shut the fuck up, and the AV3 had also shut the fuck up.
Propaganda Lies Bullshit Fake News Vast Right Wing Conspiracy Yellow Journalism
5 81 72d1ba745f0f7a35df583a06ef378df8540f6db2d365348811 ab1e29e1cddf52e115f18ee1a177b180bd9c2d0748cbd912ad e1824b92289d268fd9108dd0602490376aa0e80a094388a23d a67b154b780b78dd7ea4636eb54a8624845ace42c46005feb5 81f80485b2bd671a52ed89dcb803718638f36717fa420c99b3 094dcacdf8677789c9836ef8783d73140a616fc3d27d7330d5 03a8c5a73459631beb2cbe6af3c74628e8ca508b71f8e81b9b a5c419e9b31cc2ef21eb2cde1194b85163cbd079f5962edf69 e70e2b36b5970344e5c920495558b88a5d3252ac7f91b6710d 72d2042a0dbfc0860b41c371f148d86287af8a1450acc1060a 593450737d254ce9eacbd0e9923ea208da4ace14c5b51fd707 7d8d5b54
Scientology Scientology Scientology Scientology Scientology
anusfeast
b2dc43f5ceef31610d294fa01c6e7399baf24e5f9fc18cf
I'm PHP. I want to be an OO language now.
The only major compatibility issue that I can think of between, say, the 4.1 branch and the 4.3 branch is that register_globals defaults to 'Off' in newer versions. If you leave it that way after installing, then yes, a lot of older scripts will break. Most of the shared/virtual hosting providers I've had to do script installs on, which have actually upgraded their PHP versions, just installed 4.2x or 4.3x and then manually turned register_globals back to 'On' in the php.ini file.
Isn't 'registered_globals' a gaping security hole? As I understand it, it automatically turns all incoming page variables into global PHP variables, leaving you open to all kinds of nasty shit. It's not that harder to look in the POST[] and GET[] arrays for your parameters; in fact, it's just good software engineering.
It's like not saying 'use strict' at the top of all your Perl scripts (for different reasons) - you're just asking for trouble in anything like production code. If I don't see attention to details like that, I know I'm dealing with amateur code, or at least someone who hasn't been doing this long enough to get bit yet.
I agree at the surprising number of hosts who simply haven't updated, though. There are a lot of hosts still running 4.1x, and even (yikes) 4.06, who just won't upgrade for whatever reason. I do most of my coding these days on 4.2 or 4.3, and have run into plenty of belligerent hosts who refuse to upgrade from a two-year-old release. Typically I just have my clients move to a better host; the providers who don't stay reasonably with the times will eventually figure out that it's hurting their bottom line.
Like others have mentioned, this is not how the ISP is looking at it. They're not likely to upgrade something that works just fine (aside from security fixes) and breaking it for all their users just so one user can have a useful new function. That's not belligerent, that's just good business. I agree, it can be frustrating, but having seen one too many "simple upgrades" that totally screwed the pooch, I'd rather take the conservative approach.
What if life is just a side effect of some other process and God has no idea we exist?
Thank you for your opinion, Mr. Gates
Mm. The only thing lacking from PHP has been proper OO support.. now that has been rectiied. To think I was even considering Python as an alternative because of its only slightly less horrifying OO model. So Python for scripting and PHP for the web.. that's how it's supposed to be. Now I can sleep again.
Marxist evolution is just N generations away!
I'm currently running PHP 4.3.2 on Apache 2.0.45. I would really like to try out php5 without messing up php4 (to see what needs fixing before upgrading to the "real" php5, whenever it is released). .php5 (for instance), and the old version for .php? I could have two separate LoadModule lines (in httpd.conf), but I can't tell them apart in AddType.
I got my libphp5.so compiled and all, but is there a nice&easy way to tell Apache to use it for files named
I'd really like not having to run a second httpd (on another port)...
There are 010 kinds of people. Those who understand octal, those who don't, and 06 other kinds of morons.
If PHP had an official mascot the way that Perl has the camel, I'd recommend they swap since PHP looks more like a "horse designed by committee" every day.
sig != null
Any ideas if this has been fixed?
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Oracle has has ODBC support for as long as I can remember. Also, if you're using Windows, it's better to use OLE DB since you then remove an entire layer for better efficiency.
And, SQL isn't anything close to all that a real database (ie: Oracle, DB2, etc.) has to offer. Amateur programmers often completely overlook an entire layer: stored procedures. Mature databases (ie: Oracle as opposed to MySQL) has a very robust native programming language in which the code is compiled and cached in the database, making it often the best way to add business logic. (Note: whitepapers say to use some bullshit middle tier like CORBA or COM which just doesn't fucking scale, no matter what the "experts" say). The best thing that an amateur developer can understand is that something like Oracle or DB2 is a very very mature product which screams compared to any middle tier bullshit. Learn PL/SQL and REALLY build your resume.
Note: This post was written by a former Oracle Certified Developer who got paid MAD cash in the day to write web apps.
Is it just me, or are a lot of the examples from this page really confusing and unenlightening? I can understand most of it, but the examples for __get(), __set(), and__call() need some work.
__get() makes sense, checking to see if there is a value before returning it, but __set() looks like copy-and-paste of __get() that didn't get finished. It checks to see if the value is already there, then sets it, otherwise -- declares an error? The example usage afterwards refers to non-existent member variables, but not to the things it's supposed to be demonstrating.
The example for __call() is even more confusing. It looks like it's supposed to be a wrapper (for some reason) around a direct method call, but it doesn't refer to to the method that was passed in, and the usage is completely unrelated.
I assume these are just typos made by busy people, but it *is* an official page attempting to derscribe the new features of PHP 5.
I also wonder about the implications of the scoping rules. It looks like references to private or protected members are ignored? return null? That's nice, but is it good language design?
All in all, it looks like there are going to be really good things happening in PHP. I personally wish they weren't going in the Java syntax direction (not only do I not care for Java, but if you're going to borrow syntax from another language, you have to be consistent or you wind up confusing programmers of both languages), but hey, it's not my decision and it seems to work. It's a lot better than before - yay for being able to do func() -> method()!
What if life is just a side effect of some other process and God has no idea we exist?
Sure, killing the previous software seems like a logical conclusion. As my post suggested, I am quite disappointed that initial software design is considered to be The Future(TM) in essence of compatibility. As was the problem with supporting the USB host adaptor in some Other(TM) operating systems, and a major overhaul was necessary.
h hhhhhhhhhhhhhhhhhhhhhh
I like to look at software as the way Jesus Christ(R) explained in his Parable Of The Wine Bottles(TM). I can't offer a summary of his parable, as it would not do any Good(TM) to be partial; whoever in need should read it. As blasphemous as using old software ontop of new software may be, they seem to never build it to be forward or backwards compatible.
And I tell you; Jesus Christ is one great Software Developer(TM).hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
even better: (add to .htaccess file to your codebase directory)
php_flag register_globals On
I would also like to add that PHP IS A virtual machine as well.
If you are not compiling your code down to a machine executable then you need to have an interpreter. In the case of Java they call it a 'Virtual Machine'. PHP runs the same way and thus must also have a 'Virtual Machine'.
The quickest fix of all: Create an .htaccess file in your web root directory with a line "php_flag register_globals on". Of course, this should be viewed as a workaround while you rewrite your scripts to work with register_globals off.
Steve Magruder, Metro Foodist
I use PHP quite a lot and my biggest gripes are: 1. No easy way to do modules and extensions. With Perl I can use CPAN, load it right in, etc. With PHP I got to recompile PHP, and then recompile Apache. I haven't looked into PEAR but last time I looked it was still a headache. 2. For ISPs, there is no SUEXEC support for the Apache module. This creates all kinds of security holes and permission nightmares. 3. Some modules seem to be a moving target (like the socket/steams) and as already mentioned here there is little regard for backwards compatibility. You almost have to go read the user notes for each function you use to find out how it works on the various versions. With all that being said I still love it for doing web stuff. I use Perl some too but prefer PHP for web apps.
//m
I wrote in another post further down about the problems being incurred as PHP attempts to become all things to all men (and women). From CGI through Apache and IIS module through to commandline scripting tool a la the many other languages that already exist there. All this is fine and I've used PHP successfully from the development of small dynamic websites through commandline scripts on windows to return lists of files on a server and move them if needed through to a massively complicated "web application" called Ariadne -http://www.ariadne.nl that turned out to be so overly complex for no obvious reason that I wasted months trying to figure out how it worked (Java would have really been simpler and cleaner for that one).
But what alwaqys got me was the argumentation behind the decsision to turn off register_globals by default. (This is also partly a repsonse to another post further down) The logic went that variables could be spoofed by an end user in order to gain access to "private" data as the variables are automatically created by PHP. I'm by no means an expert on security matters, but AFAIK there are different approaches to security in a language. One is security by design as it exists in Java (and by all accounts works extremely well), another is security in the actual software design. This means in php that you don't use the same php file for all your sensitive database connect statements and front end html output for example and that you don't use things like if ($goodboy) OpenForBusiness(); etc.
Chopping off this only served to irritate web scripters and only marginally improved security because most scripters simply turned the auto variable creation back on and security by limiting features is not an answer IMO. You can still crack that $HTTP_POST_VARS[goodboy] or $_POST[goodboy] by bruteforce methods if you think you have something to gain by this.
If I understand this completely wrong please correct me, but I simply see php as becoming another Perl and we already have that.
Intelligent answers deserve intelligent questions.
I mean seriously...are you stoned? What is your point?
Ever since the Model T... cars have had engines. But to hell if you'll be able to easily get a modern Ford engine to work in that old Model T. I mean thats an example of a something (an engine in this case) not being backwards compatible. It still does the same thing. Maybe they shouldn't version engines anymore, just call them something else.
Today engines can have turbo chargers, enhanced emission controls, variable valve timings, direct port fuel injection, etc. Drastically different and definitely not compatibily with older cars. However, they still make the wheels on the vehicle go round. They deserve to be called engines, regardless of the variations or enhancements or complete swapouts of thier subsystems.
Original design goal of the early engine was NOT fuel effiency, was NOT low noise, was NOT long life, was NOT lower emmisions. It was to help make the wheels go round.
Realize the end user names are not for your benefit as a scientist, engineer, or some BSing PHP/Perl programmer to recognize significant changes in implementaion. The are used as an identity for that project. End users can say, "oh, I have windows 98...here is a windows 98 compatible program. I can run this."
I seriously doubt your parents design goals for you were PHP/Perl programmer, or even anonymous coward. They probably gave you a name along the lines of Jack MeHoff, maybe even with similiar design goals.
No.
There's no such thing as "public performance" in software copyright law.
Let's break down the definition of "public performance". According to 17 USC 101, "To 'perform' a work means to recite, render, play, dance, or act it, either directly or by means of any device or process". I'd assume that running a program would be considered "act[ing] it ... by means of [a] device".
The same section defines "publicly": "To perform or display a work 'publicly' means - (1) to perform or display it at a place open to the public ... or (2) to transmit or otherwise communicate a performance or display of the work to a place specified by clause (1) or to the public, by means of any device or process". From the statute, I reason that opening up a public web interface to a program constitutes performing the program publicly, which is the copyright owner's exclusive right under section 106.
In addition, even if this public performance angle doesn't hold, the DMCA's circumvention ban may make EULAs into binding contracts because it's impossible to gain access to the copyrighted compiler without going through or around the access control mechanism known as the installer's EULA screen. Contract law typically requires an offer, an acceptance, and consideration to create a binding contract. OFFER: the displayed contract. ACCEPTANCE: "I Agree". "CONSIDERATION": Microsoft authorizes decryption of the cab files; the user sells his soul.
Now that I've shown the statute, do you have case law to back up your position?
Will I retire or break 10K?
The only reason your statement is even partially true is because there are so many shitty "programmers" out there who can't even understand the code they write themselves and feel lucky any time something works, or pull out their broadsword to fix random problems that pop up and then pile crap on crap.
In summary:
http://blogs.phparch.com/mt/archives/000014.htmla .
http://blogs.phparch.com/mt/archives/000019.html
http://blogs.phparch.com/mt/archives/000024.html/
What is the goal of English?
What is the goal of Perl?
As you can see there is no specific goal other than the general ability to communicate with the computer. And as any human language, programming languages should have the ability to evolve with the times as progrmmers aquire new habits and tastes. Languages are designed to serve the programmer. If a language stay loyal to their own goals, its speakers ( the programmers ) will begin to evaporate. Adaptability and change of goals is a very important ingredient to the language. This is certainly true for perl.
You will find more info about languages in Allison's article at www.perl.com Perl Philosophy .
To the best of my recollection, there isn't much else that's not backwards-compatible.
Somewhere between php 4.1 and 4.2 (IIRC) the get_object_vars simply changed behavior. It used to only return an array of object properties which had values (not null), then suddenly after upgrading it started returning *everything* even if it was null. NO documentation change, nothing in the changelog - nothing. I was more than a little surprised that such a fundamental behaviour was changed and not noted *anywhere*, when much lesser things get listed in the changelog(s) all the time.
creation science book
I've heard that PHP does not have (or did not have) support for function overloading and that this omission was intentional.
Personally, I really like function overloading. API's get pretty hairy when you have multiple functions that all pretty much do the same thing but do it with slightly different inputs. For example, let's say you have I want to get the bank balance... it looks cleaner (to me at least) to have something like this...Than something like this This isn't a great example, but I've seen Java classes with a huge number of methods, with each method overloaded around 3 times. Seems like a pain to bloat your API by not using overloading. Obviously the developer of the API has just as much work either way but the consumer of the API would have a much more consusing time.
So, could someone from PHP crowd explain why overloading is bad? Not trying to troll, just honestly curious. This might be a moot point -- can you overload functions now in PHP5?
In case anyone is interested, I've followed the PHP5/MySQL on my blog. (it also contains instructions for getting MySQL back into PHP)
Sarcasm is often (usually) ironic.
I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace (as opposed to one URL -- how very un-spider-friendly. Most choke on a ? in a URL and rightly so)
Midgard will do this for you using the Active pages concept.
Midgard Project - Open Source CMS
PHP is usually run as a apache mod or sometimes, as a cgi. Because of this, it cannot store session state or cache inside of its process (since the process is either apache httpd, or the cgi, which terminates at the end of a page run).
This is also, why PHP can easily be hosted and maintained in a shared environment and Java usually can't. You'll find a lot of commercial web hosters offering you a directory and a shared PHP interpreter for very little money, because running PHP does not incur the overhead of an application server instance per application.
On the other hand, if you had a large PHP application that used a lot of state, needed a connection pool and needed to keep compiled code in memory, you'd probably install SRM, the script running machine. SRM is basically a persistent VM that runs precompiled PHP programs called Bananas in a way very similar to what Java does with Beans.
Kristian
We ended up running cron jobs that would reboot the farm, round-robin, just to solve memory issues and instability.
PHP is often slammed for not keeping state across requests, but saving serialized state to disk and reloading it on the next page. While this seems awkward in an ideal world, it is often the right thing to do in the real world.
PHP does incorporate very many (often more than two dozen) client libraries written in C by third parties. These come in very different levels of maturity and many of then are not only unsafe to use in a threaded environment, but also have memory leaks or other spurious problems. The default execution modes of PHP (throw away all memory at the end of the request) and Apache (execute each PHP interpreter single threaded in a separate process, but reuse the process) is very suited to run such libraries in a stable manner even if the code being executed is slightly defective.
The end result is often that PHP application run seemingly stable and use very little memory, whereas a comparable Java application leaks memory over time or has stability problems (one thread dies, killing the entire process with it).
Kristian
If you want "persistent process outside of the apache process", this is exactly what FastCGI is. PHP can be built as FastCGI application. Although this is, like in-memory session storage, is very rarely used in "any serious, large web applications".
namespaces was pulled from php5 because the php developers couldnt' figure out how to do it. (read it for yourself on zend.com)
we'll be switching to java, thanks. (after waiting for fucking months to develop our software further because we were told namespaces will be in php5)
extract($_POST);
extract($_GET);
extract($_COOKIE);
Sure, but that doesn't fix the problem - that assuming that a variable is set by a cookie when it may as well be set by a GET variable is very unsafe/unwise/unsmart...
Instead of ODBC, you'd be better off using the pear/db module as middleware. It supports more databases (mysql, odbc, sqlite, pgsql, etc.) and if it isn't the future standard for database access in PHP, something like it will be.
I've been using PHP's built-in (until now) MySQL functions, because they're faster than pear/db, but this licensing dust-up has convinced me that portability among database vendors is worth a performance hit. And the pear/db module is getting increasing attention and is likely to get faster.
To put it simply, a servlet container runs java objects that extend the abstract HttpServlet class. At the heart of it, the servlet container will provide you with a HttpRequest, containing the session and any objects stored in it, cookies, request headers, etc., and HttpResponse, which contains a PrintWriter that you can use to output whatever you want. Servlet containers also do things like user authentication and application management. There's quite a lot of configurable options for this stuff.
With J2EE being all the rage these days, there's a lot of inertia behind writing MVC web apps. Writing apps in JSP has nearly the same maintenance hassles as writing them in PHP. Instead of writing a JSP/PHP page that checks that a user is logged in and creates connections to a database, the idea is for JSP to deal with presentation and servlets and java beans to manage the database connections and "business" of the web application.
Some of the cooler (newish) tools that people are using with servlets are XDoclets and object relation persistence
So... take a look around. I strongly suggest checking out the Struts Framework. And this IDE's not bad. And this tool is pretty fun. I mean, I use it...
"It's Dot Com!"
I'll second that, I'm using PEAR DB on several high traffic websites, and while it is slightly slower, it's also a lot more friendly to use.
how so? It's trivial for someone malicious to edit the cookie text file to hack a site that trusts say $_COOKIE["isRoot"]. It is client side too. Any one of those three could be unsafe.
Also, I was merely pointing out an easier/cleaner way to replace the kludge in the parent post. I still don't think register_globals is quite the security hole that people make it out to be though.
bananas like monkeys.
All you say is true. However, it is more a question of how the following code is written of course. I didn't mean to come off like you didn't know your stuff - if I did I apologize. The problem with the register_globals approach is that people are not aware of the possible security holes it creates and uses it in unsafe manners. SQL-inject is easy if you treat a variable unsafely.
I always thought that the whole point of PHP was to be a NON-Object Oriented language.
.....
.....
I mean, call me old-fashioned, but I prefer telling the computer how to process the data, rather than telling the data how to let the computer process it!
Look at JavaScript for a freakin' awful example. In any sensible language, if you want to find the length of a string, you call a function and pass the string as a parameter. In JavaScript, you have to read something like foo.length, which most probably is making a function call "behind the scenes" but it's this abstraction layer that causes bloat. Either it has to measure the length of the string every time you access the property, which takes time, or it has to measure it every time it changes and store it, whether you want it or not, which takes space. And it all adds up - it's called the Ton of Feathers Effect. Why should I have to buy a faster processor, more RAM or a bigger disk simply because some programmer can't be arsed to shave a few clock cycles or a few bytes off here and there?
If I want to measure the length of a string, I'll call a function to find it out; and if I want to use the value ever again, I'll store it in a variable. If I just want to act conditionally on the length and not care about the actual value once I've chosen a branch to follow, maybe I'll even put the function evaluation right there in the conditional.
Microprocessors don't, as far as I know, have strong typing or object-orientation. This probably is for a very good reason. They are completely artificial concepts.
What I'd REALLY like is a "forget" statement, so I can say free up the space that was being used by one variable and park another variable {any one that will fit, I'm not fussy - say just the next variable I declare} in there. Oh, and maybe a "pretend" statement {just for debugging purposes - I can't see it being any use in real life} for making temporary assignments that will be undone immediately after the variable is read.
e.g.
$foo = 10;
pretend $foo = 5; next time, and only that one time, we look at $foo we will see the value 5
if ($foo == 5) { test passes, but $foo goes back to 10 immediately once read
}
Sod it. I'm off back to my little shack to practice "Identifying Edible Objects In A Forest for Beginners" and "A First Course in Not Getting Eaten".
Je fume. Tu fumes. Nous fûmes!
#!/usr/local/bin/php
<?
phpinfo();
?>
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Even if you stick to ANSI SQL (which version?) most databases have too many differences and you can greatly optimize things and make life lot easier for yourself by using the tools available in the database. And then I haven't even touched stored procs yet!
Middleware suck. The whole pg_connect(), syb_connect() in PHP is silly, though. The least you can do is create your own getConnection() and such. ADODB is OK for useability, but it is painfully slow to include on each page.
Use mod_rewrite to have certain URL patterns handled by a PHP page. Works wonders!
This looks interesting... I am however unable to download the demo. Is there a lits of mirrors anywhere?
....Or just write your own minimalistic layer. Its not a big deal, and you suffer no performace hit.
If you really narrow it down, its perhaps 20 lines of code in to support the different function names and a couple of lines for a different database connect.
IT DOESNT WORK ON APACHE2
/home/myhost/engine.php/ /res /home/myhost/resources/
...but it rather lacks the elegance of the Apache1 version. Not to mention the request path HAS to go through mod_alias now. Blech.
Damn it. The following does:
Alias /
Alias
.
Does php5 play nice with the threaded MPM in apache2? It would be nice to actually be able to implement real database pooling in php.
Hmm, experience says that for server-side stuff this probably indicates that someone hasn't told these programmers about the difference between String and StringBuffer. It's amazing how many Java programmers (including many who ought to know better) just don't get it.
Comes of hiring monkeys for peanuts instead of Real Programmers (for caffeine and something disgusting from a vending machine!
"Little does he know, but there is no 'I' in 'Idiot'!"
PHP starts to get interesting... When they release PHP 7 I might switch from Perl to PHP.
If it ever really gets off the ground, this project plans to change that.
My comments were based on experience. I'm a software developer that has worked on several commercial applications over the years, for a variety of markets. What is your commentary based on?
Every piece of software has a life-cycle, and version releases are just levels of maturity until the project is no longer worth the time and effort to put into it.
Whether or not you practice good release management has nothing to do with this fact. Those goals you speak of are for releases so that you can keep a lid on creeping featurism and not introduce new regressions. There is rarely, if ever, a penultimate and overarching engineering plan for any significant software project. Most developers aren't even totally sure what the project will do, or who will use it. It is the implementers that often drive most of the development changes over time. Take a look at this slide. Note the "maintenance" bullet. That is where the majority of your time and money is spent on a software project over the whole of it's life.
Software development lifecycles and management practices are well known. You might want to check here and here as well. Note that these are CompSci theories. In the Real World, software development rarely works out so cleanly.
In summary:
The second item does not indicate anyone "sucks". It's a fact of software development. Some projects have a longer life, some very short. It all depends on what it does, and who is using it.
-- clvrmnky
Those new arrays are not necessary. They could have changed the language to include a simple declaration of what variables are inputs, like define-input in BRL. This eliminates all the security issues and is nearly as simple.
There comes a point in cooking where one more spice, one more ingredient takes away from the whole rather than adds to it. I believe several languages lately have had that problem. Perl has obviously gone too far--and lost it's simplicity, and it looks like PHP is going the same way as well. Maybe PHP 4 is good enough to call "done" If it gets much more complex, new users will be confused and something else will take it's place. That's why BASIC has been around forever it seems--It's not the greatest, but it stays put so everyone can start somewhere!
Many of the .com era technologies are great ideas, but need development in to lean, mean, systems. I'd propose a 3-5 year hold on any new versions just to let the environment settle down and give time to let the systems grow from "really good" to "legendary".
Would be nice if all you trolls actually did some research before getting all bent out of shape about things.
n -l egal-200306/msg00061.html
http://lists.debian.org/debian-legal/2003/debia
The GPL license (which MySQL has recently switched to for its client libraries -- from LGPL) does not permit non GPL software to link to it. This means that if PHP provides linking to the GPL version of MySQL's client libraries (the 4.x version and later versions of 3.x) it is breaking the law and that would CERTAINLY be "not a smart move".
Because there are still LGPL versions of the MySQL (3.x) library available, PHP can continue to include the mysql extention for users to link against their own copy of libmysqlclient without having to worry about licensing issues. This is a good thing.
In order to support the newest features in MySQL however, one must use libmysqlclient >= 4.1 (they changed the protocol) which requires a different PHP extention (not available due to licencing issues stated above).
MySQL authors are "working on an exception" for PHP, but at the moment the ball is entirely in their court.
I allus have disliked Perl, 'cause the code tends to look like the keyboard sneezed on the paper. I've had some concern about PHP going the same way. I prefer PHP to just about everything else, but...
:O)
.h files in the target machine's include directories and builds a glue library for those libraries. At least for C++ libraries, there's enough info to build a glue class. This would provide a semi-automated library constructor mechanism and ease cross-language programming.
From its early tight-albeit-primitive beginnings, PHP seems to have gotten larger and larger, with a fairly incoherent library naming scheme that kinda, but not really, follows C/C++ conventions. I can no longer know all of PHP without constant updating and study, which means I have a high likelihood of not writing optimal code. I don't really want "more than one way to do it." - well maybe two. or three.
The lack of fibrary coherence is frustrating. I spend too much time looking in the docs to see which calling and return convention is used for each function, and how a function is spelled. To make things harder, the function docs are not explicit in the function summaries about what, if anything, is returned.
I haven't looked at the PHP5 specs. I have a couple of hopes. The major one is that the language itself will have been pruned down, and most of the libraries separated out as loadable modules. The second is a redesign of the entire library system (in this or some future version) to provide a single, coherent API-face.
The kitchen-sink approach was great in getting PHP to be the most popular web programming language, but it's time for some discipline. In particular, the syntax convention for using common C library calls is decidedly mixed up in PHP4. Too many of the function libraries are apparently 'first cut' hacks that got something working but were subjected to any design cleanup.
Suggestion: There is a parallelism between the PHP libraries and standard C, C++, and POSIX libraries. It's reasonable to consider a kind of meta-library in PHP that, at compile time, reads (which ones of?) the
PHP4 has adopted various 'features' that make programmers in other languages more comfortable but are bad ideas. For example, assignments within IF statements may be a convenience, but it is a primary cause of coding errors, because, e.g., "if (a=b) {foo();} is no longer syntactically testable for a minor, and very common, typo. The compiler has no way to know if you meant to assign b to a, or to just test for equality. This is a BAD THING. The required vigilance and difficulty in debugging negates the convenience. Now it is a problem in PHP4. I'm sure there are a number of pieces of PHP4 code out there with exactly this bug in them.
PHP design needs to get back to the roots of what made PHP better for its primary uses, instead of following all the bad ideas of other languages, just because folks are used to them.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
That's an interesting comment. I have done exactly what you described, and found that I needed only five functions:
connect_to_db()
-connects to the database and returns the connection token
-also, caches the connection token, to save having to do it a second time
get_sql_array()
-given a SQL SELECT statement, this returns all fields in an array
get_sql_array_of_hashes()
-given a SQL SELECT statement, this returns an array of hashes, where each element in the array represents a record with a hash, where each key in the hash is the name of the field
execute_sql()
-given any SQL statement, this executes it and returns a count of records affected
sql_quote()
-given a string, this function escapes the string and encloses it in single quotes, appropriate for inclusion in a SQL statement or query
I only ever call the last 4, since each (except sql_quote) calls connect_to_db().
I have versions of the above 5 functions for connecting to MS SQL Server, MS Access, and MySQL in Perl, VBScript and PHP. I have little problem switching between Perl, VBScript and PHP since these (and many more) functions are available in all three.
If another database or language comes along, I can have my mini-library ported in an hour or so, since, as The DOD player noted, it is only 20 lines or so of code.
In the last year, we have been doing projects almost exclusively in PHP, and I have been considering moving to the Pear DB library. Anyone care to comment on their experience with Pear?
Mike van Lammeren
It will challenge your head, your brain, and your mind.
I'm glad to see the PHP Guru checking out the /. posts, and participating. Thanks from the community!!
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Any site that stores auth data in an unsigned cookie is asking for trouble anyway , of course 'register_globals off' can't protect against that. It will, however, protect you against variable injection w/ uninitialized variables, which is definitely a *good* thing. Even the most careful of us can make mistakes. One less thing to worry about.
Languages/APIs are meant to make it easier to do useful stuff and harder to do stupid things.
The fine line between hack-and-slash-just-get-it-done coders and software-development-as-deep-science is actually wide enough to capture a lot of real world projects. Not every software project is an operating system with continuous iterations.
Consider a small software project that ends up as the code embedded on a miniature computer attached to an oil pipeline sensor array, buried underground. Or a pacemaker. Or any number of other areas of engineering where it's actually important to get it right the first time, and you don't have another chance. These are just a few obvious examples.
And I would expand my point to be even more general, which is to say that just because intellectuals expound on a subject, the scope of the subject is based on our (you and I and whoever else is discussing it) idea of what it is, not the intellectual's. In other words, just because Brooks or Royce or Joel or anybody else provides a template for projects does not mean that all projects fall under that template.
Perhaps my comments in the post to which you responded were a bit harsh and overly specific (and I apologize if I've offended any bad programmers), but I think in a sense we are both right (though obviously I am more right than you).
Nothing throws a code 500 to the webserver, all they do is crash :)
That error is generated by the webserver when a cgi process either dies or fails to return a valid set of headers.
PHP is able to keep going through a large amount of errors and still render the rest of the page intact, which is imo the correct way to go since it is perfectly possible for the programmer to use the header() commands to create an errormsg 500 response if needed.
Too bad that PHP doesn't come with easily accessable documentation like most other languages on a Unix system.
Yea like the regexp manpages or sed/awk. What other languages exactly? The manual is online in 25 different languages, with local mirrors in most countries, browsable online or downloadable in about 8 different formats and searchable in the internets #1 search engine. How could it possibly be more accessible?
Typing 'log errors' into the 'online documentation' search directs me to a google search of the entire site that does not produce the page you're refering to.
If you type "log errors" into the search engine without selecting any options then the error_log page is the first one you get and the second is the page explaining the entire error handling/logging functionality. Perhaps google is doing something strange due to your location/IP address?
Maybe you'd want to look into adodb.
New things are always on the horizon
In both the United Kingdom and the United States, a computer program is considered a "literary work", which is defined in section 101:
Neither in statute nor in case law does the definition of "literary works" extend only to those written in a natural language.
If you disagree that computer programs are "literary works", please reconcile with 17 USC 102, which doesn't mention computer programs explicitly at all.
Will I retire or break 10K?
Quote from my very last response:
Obviously, there are a variety of ways to approach software development, and for cases like embedding software in bodies, space craft and remote industrial devices, we have to take these practices with a grain of salt. I said as much in my last comment.
However, the exception does not make the rule.
This did not start with a talk about embedded systems. This started with your comments about software names in general and PHP 5 in the specific. It is unlikely we are going to send PHP into space any time soon. There are other more tried and tested technologies we use for that purpose.
I was responding to those comments, wherein you suggested that it was misleading that PHP 5 might no longer be "PHP" simply because it has gone through 3 public major releases, and the language has changed somewhat incrementally over the years. My response was simply, "that is what software does".
Honestly, I found your orignal comments confused and misguided, and many of your assumptions lacking in logic or not based on real experience. I still think you've missed my main points which I've carefully and neutrally discussed over the length of this thread.
So, I'm going to assume your last comment was a joke; even if it wasn't, you can consider this next comment of mine as humour, also.
You are entitled to your opinion, as we all are. The entitlement, however, does not make you "right" in any sense of the word. I disagree that your are correct about your original comments in any way until you are able to argue your case clearly and logically, without any ad hominem attacks or straw-man arguments.
<span class="old-timer">
My advice is to get a little education and experience under your belt before making sweeping judgements about software life-cycle management.
</span>
'nuff said.
-- clvrmnky
I welcome this change; philosophically I think that the inclusion was one that should have never been there in the first place.
Anyway, to those people whining 'What about when I can't compile the bin?' - welcome to the real world. What about those of us who use a different DBMS than MySQL? We get by, and so you will, too.
Thanks,
--
Matt
Just compile it with gcc. gcc is available as a binary for Windows as well.
So you're saying I can compile PHP and MySQL in MinGW? Why didn't the documentation say so?
Will I retire or break 10K?
There's a difference between requiring Windows and requiring Visual Studio. Windows is $300 by itself for one seat or bundled with 99.odd percent of all PCs. Visual Studio, on the other hand, is over $1000 for one seat and is not typically bundled with PCs.
Will I retire or break 10K?
I have heard that pyDDR is good, but I have a PS2, so I can play RealDDR
Can you play "Around The World" by Red Hot Chili Peppers in Konami's DDRMAX? No. DDRMAX does not support adding recordings from CDs.
All Comcast seems to care about is that your system does DHCP properly.
I guess Comcast does "just work".
I guess you must actually check your posts via your user page too.
I have notification turned on.
If I do go to Linux in the near future, it'll probably be Knoppix in the CD-ROM drive (F:) that I never use anymore since I got a burner (G:).
Will I retire or break 10K?
- The SQLite extension is now bundled and enabled by default.
- Removed the bundled MySQL client library.
The MySQL client libraries have been GPL'd. That means people that make a living creating PHP/MySQL based solutions that they wish to remain proprietary are forced to buy a license from MySQL to get around the GPL stipulation that there code must be open. This situation may change as there is talk between the PHP dev team and MySQL to work on a solution that may exempt PHP. It's still up in the air, but until a conclusion is reached, MySQL is no longer bundled. SQLite is really not a database, but an SQL interface for a flat file. MySQL is overkill for most sites anyways. It's extremely fast and it can be run anywhere. The host doesn't need a database installed. So for most sites that don't really need all that a RDBMS can offer, or their host isn't capable of providing it, SQLite is really a great alternative. Good for hosts as well.
The unexamined life is not worth living
a few facts:
1. MySQL support is not gone. Only the bundled library is gone. You can still compile PHP to use MySQL, and will be able to do so (in a similar way you can use Microsoft's SQL server from PHP, but that doesn't mean that PHP is shipped with Microsoft SQL's server code - see the difference?)
2. There are very good chances of MySQL making an exception from their 'GPL way or the highway' rule for PHP because close PHP+MySQL relationship is very benefitial for both of them. Such an exception is in the talks right now, as I am writing this.
3. MySQL 3 client, which has been bundled with PHP for a long time now, can still be bundled, if someone felt the need to do so. It's only MySQL 4 client that is GPLed in such a way that it's not possible to put it into PHP.
Plus, a couple of rant points:
a. While it sucks, there is nothing wrong with MySQL AB creating that whole licensing mess - they have the right to do so, and, more importantly, they have the right to earn their living, which is what they are trying to do.
b. I do not know why this made it to slashdot in the first place. PHP5 beta should really (IMO) be considered alpha at best. The code is not only not in code-freeze, but a few aspects of the API have not been hashed out yet. There will be major changes coming in the new beta-2, if that's how it will be called. So, consider this a very early release, try it if you feel but do not expect it to work reliably. Moreover, do not even expect the final PHP5 to closely resemble what you see in this 'beta'.
Jobs? Which jobs?
Both you, kris, and anthony would probably do yourself well by taking a look at Jetty or Resin.
:) I have a hard time believing he was serious though, I woulda probably modded him as funny. It's sad someone actually fell for his post. There really is no speed or stability difference, it's just easier to make small sites with PHP, and large sites (or integrate with legacy systems) with J2EE.
Java doesn't leak away memory unless you are running in a Solaris machine, or someone coded a class that keeps pointers to objects that should have died long ago. If you don't handle state properly, and you keep it in memory but don't periodically check to see if it expired, of course you are going to have problems.
Some JSP engines store persistance on disk, in a database, or across a cluster in either variety as well.
When people quote Tomcat and JRun as reasons why PHP is faster than JSP, I just want to shoot them in the head. At least give Jetty (open source) a chance even if you don't give Resin ($$$), BEA ($$$), or Websphere ($$$) a chance. I wouldn't trust Macromedia (JRun) to make any server-side product really... Anyone that thinks you don't need a sine function in a language to display flashy graphics obviously doesn't have much going on in the head. Tomcat was a donated reference implementation. It's primary goal until recently seems to have been stability. Now they seem to have switched gears for performance. Jetty on the other hand is appearantly programmed by a savant. Within days of the release of NIO, he seems to have reworked the entire engine to support NIO. I really don't see how anyone could not be pleased with jetty though. I set it up on a dual processor server at the local university, and classes of 15 start and restart Jetty and they don't complain about speed at all. JBoss embeds Jetty because it's so good. Jetty doesn't support working through Apache (that's what makes Tomcat slow more than anything I would say), so you may not be happy with that, but just about any project worthy of J2EE is worthy of 100$/mo dedicated hosting.
Be sure, in any case, to try different VM's to see what works best for your project. The IBM JRE seems to be the fastest, but some argue that BEA's VM (JRockit) is actually faster for server-side stuff. Both should be free, but I'm not sure of the licensing terms.
I've seen some other FUD around going the other way too. PHP's Zend compiler is a JIT compiler as well. The speed of the two should be comperable. They both have their place, but I will probably never recommend PHP for large projects because it's so hard to seperate the logic from the presentation, where there are at least 3 tools to do this with Java.
If the future of the Web is rich clients, I'm curious if PHP+Javascript+XUL will turn out better than Java Webstart. It will be interesting to see what happens, but I'm banking on Java because of the massive numbers of backers in the industry.
I hope no one got the wrong idea, but I love PHP too, and am very excited about the new version. But that one crazy AC trying to compare Java and PHP the way he did was just silly
Karma Clown
As for the branch that our little sub-thread took, I only responded initially to your statement (emphasis mine): I accept that you in a later post acknowledge that "In the Real World, software development rarely works out so cleanly." My issue was with your extremely absolute mandate regarding the eternal nature of all software projects. No doubt I brought no new insight to you with what I said, since I am sure you knew it already to be true and employed hyperbole for the sake of making a point, but that can be a dangerous logic game to play. I am glad we are now in agreement (I think).
And yes, when I said "I am more right than you" I was kidding. But as far as making "sweeping judgements about software life-cycle management," I feel you should swallow that pill, for it was I who was massaging your own sweeping statements by pointing out counterexamples, not attempting to make any bold claims of my own.
I also hope anybody who is still reading this thread is enjoying it.
My apologies. I had assumed you were the OP. I generally browse threads with all AC comments disabled, but must have turned that back on during moderation.
As for the statement you take umbrage with, I still stand by the exact quote. Perhaps my opinion is slanted because I mostly maintain code for a living.
I never run out of bugs to fix or features to implement between major releases, and have seen a few products age beyond their useful life until a complete rewrite is warranted. Between maturing customer needs and ever-changing hardware, I just don't see that changing much in the near future, especially in the enterprise client-server world. No matter how hot your coders are, and how well the project managers do at managing the project, there is always post-release maitenance. This is my specialty, and it has served me well.
As we've discussed, there are a lot of exceptions to this. I've been out of embedded market for some time, but was once involved in the planning stages for an aerospace project. The specs on that one changed almost daily, and we had one chance to get it right.
However, it is unlikely that PHP will ever go to space in the near future, and PHP is what got us this far into this discussion. Very odd.
-- clvrmnky