The greatest change in PHP 5 comes with a complete redesign of its object model, and with it, a tighter integration to object-oriented (OO) paradigms. Previous versions' usage of objects had one major drawback: Objects were not tightly aligned with the behavioural patterns observed in other object languages like Java or C++. While PHP offered a simpler approach, the disparity created a considerable chasm for those wanting to use PHP in a truly object-oriented manner -- in the sense of what the industry perceives as object-oriented.
The first technically deficient issue surrounding the older object model was the fact that objects were passed around by value and not by reference. To a seasoned object developer, this created a series of pitfalls in the creation of object hierarchies and execution of operations, some of which could be resolved through cryptic syntax. To technical observers, this made PHP a bloated object technology, since it continuously created clones of objects being passed around on every invocation.
Now objects in PHP 5 are passed around by reference as a default behaviour, in much the same way other object-oriented languages do, making it easier to work with for those experienced in object languages, while preserving almost transparent backward compatibility with the older PHP object model.
At the core of this PHP shift is the second version of the Zend Engine, which powers this new behaviour of object references through special handles which are assigned to each object instance. The core PHP engine also incorporates more object-oriented features:
Besides these enhancements, which are typically found in OO languages, there are many other new features similar to those found in Java or C++. However, the other central enhancement in PHP 5 is its tighter integration and faster execution when invoking components written in Java or .Net -- possibly the two most adopted development platforms in today's market -- all of which comes as a result of the engine redesign.
PHP 5 also takes a revamped approach to another pervasive technology: XML. The newest PHP version uses the open source libxml2 library for core XML tasks like DOM and SAX parsing and XSL transformations, substituting the previous PHP versions' approach of using a hodgepodge of libraries. SOAP support, as derivative of XML, was also rewritten as a built-in C extension in PHP 5, providing an enhancement over the widely used PEAR module (written in PHP) used to execute SOAP applications in older versions.
Another area which was also revised was the interaction of PHP with mainstream relational databases -- a typical component used in Web applications. The PHP 5 distribution incorporates a new MySQL extension which allows applications to take advantage of the features included in MySQL 4.1 and later versions, such as prepared statements, SSL, and transaction control. Support for SQLite, an embedded SQL database, was also added to PHP 5, allowing for a lightweight alternative to a full-fledged database suite while leveraging the newest object-oriented features in PHP.
Other provisions included in the latest PHP release are the execution of Perl scripts from within application code; the use of Tidy, an open source library used to analyze and parse HTML code; and a new memory manager for enhanced RAM utilization.
Daniel Rubio is the principal consultant at Osmosis Latina, a firm specializing in enterprise software development, training and consulting based in Mexico.
Note: Comments are owned by the poster. We are not responsible for their content.
Silly you! You think backward compatibility is a good thing... the important thing in this business is not for stuff to work, it's to have a vexing "new look" and to integrate more and more and more tightly into<nobr> <wbr></nobr>.shet and java. (If I wanted that kind of memory footprint on my webserver, wouldn't be writing it in PHP)
More seriously, I think you should just submit this as a bug report. Backward compatibility is broken, so as to please some manifestation of the O-O marketing god, or a particularly squeaky wheel. That's a bug, or more properly, should be considered a high level design bug in the open source world, when that much old code is broken.
No wonder strict GPLers had earlier rejected PHP4 when it came out. Wonder why? I think it's time to revisit their decision, and see where that fork went, in case the PHP developers refuse to listen to their HUGE user base. Communication is a good thing... Thanks for bringing it up.
<TT>$a=array('a'=>1, 'b'=>1, 'c'=>1, 'd'=>1);</TT>vs:
<TT>a=['a':1, 'b':1, 'c':1, 'd':1]</TT>what is a hellava lot more readible? Python is smaller, more readible and easier to type.
Is that really good?
Posted by: Anonymous Coward on October 21, 2004 02:05 AMWith the old system I could:
1) If I wanted to copy an object while passing to function, I would just pass it to function. Like in php4, or C++.
2) If I wanted to pass it by reference, my function would indicate that it accepts a reference.
Now, I have to differentiate between objects and POD types, so all my generic type-independant functions now require rewrite.
Even worse, if I want to copy it the old way, now I have to explicitly copy it. And I don't understand, what's wrong with a simple & in front of a parameter.
Let's take a simple stupid function, like this:
function add_to_something($v)
{
if (is_NULL($v))
$v = DEFAULT_VALUE;
$something->add($v);
}
Of course, this example is really stupid, but it still shows a point.
With the new mechanism, you would overwrite the old value of $v IF $v were an object, but would leave it untouched if it were a string or int (or any other POD). This gets worse if you are extending a pod-parameterized function to support objects, and so on.
Now if they only would allow something like const reference (to force avoiding the pitfalls) or a simple syntactical thing to force an old behaviour, that would be less annoying, but with the current methods, it's simply non-usable.
#