Slashdot Mirror

It's much more about the users than the OS. This could just as easily have been about how setting you root password to "admin" with SSH-as-root enable can be a dumb thing. Or how, as in my case, a server can be hijacked (or at least attempted-hijacked) when your roomate with an SSH accounts has a password that is his own name (his account name also being his name).

Windows is often less secure by design, but PHP attacks could just as easily affect windows machines running PHP (their just less common). One should never assume invincibility with any OS, and the risk goes up with the greater number of applications you install.

Good documentation makes all the difference - look at the PHP manual for a prime example http://php.net/manual/en/

Every page should describe one item (with examples) and have a moderated discussion *on the same page*.

Another useful addition to said manual could be a series of more abstract articles covering coding techniques, best practices, and common applications... again with a moderated discussion per article.

I find wikis just don't work as well as they could here, nor do forums or plain vanilla manuals. Combining the above elements from all three make what I would consider the best resource available.

Well, that's my $0.02 (CAD)

Kieran

It's completely dependent on what language I'm coding in.

When I was coding in PHP... php.net was an absolute godsend of being both a reference to all the functions and objects and a repository of user's experiences and tips for the items... almost all of my php issues were solved via that site.

When I've been doing Javascript code (which isn't a huge amount I'll admit), then I've found W3School's reference pages to be invaluable.

Now that I'm doing my coding in the open source language Laszlo I've found their included documentation that comes with the developer install (web based and with live examples to tinker with), and the community coding forums to be an enormous help, and have made learning and getting a lot out of this language really not that hard.

I really think that trying to localise coding support isn't going to work... the coders should just make use of the best forums and resources for the language they're using. Each time I have to use a new language I have a new folder in my bookmarks for reference pages and forums for that language that I find on the web... you find almost everything you need that way really.

And know how to use Google damn well!

The more important PHP site to me is php.net. I type http://php.net/function_name into my browser all the time. Even if I owned a reference book, this method is still faster. I'm already at the PC anyway.
--
Find the lowest price at PriceAge. Comparison Shopping with online coupons.

With components like DB::DataObject, HTML::QuickForm and DB::DataObject::FormBuilder building web DB applications is shockingly quick!

PHP catches a lot of flack because it is by far the most popular language out there for building websites which offends the crowd who want work with a language only the ubergeeks can use.

The thing is that a clueless newbie can be productive in less than 2 weeks with PHP (even though looking at his code will make your eyes bleed). While for more experienced programmers its very easy to use things like the object features in PHP5 combined with template tools like smarty and db libraries like ADODB to create stable, maintainable and fast sites. For most small to medium business owners it's a really good choice because the openness helps keep down development costs and if one developer doesn't deliver its easy to find another who can.

When it comes to security the real truth is that it doesn't matter what language you use, if you don't check the user input, you WILL be sorry. Every 3 months or so I'll have a customer upload a formail.pl script from the 1990s and I'll end up having to clean up the mess once the spammers start exploiting it. Most of the security problems with PHP tend to always occur with the same small group of popular packages (phpbb, postnuke, etc.) written by people only worried about the functionality not about the security)

Note: The PHP 4 method of declaring a variable with the var keyword is no longer valid for PHP 5 objects. For compatibility a variable declared in php will be assumed with public visibility, and a E_STRICT warning will be issued.

Only thing I've ever needed to read to learn PHP is fr.php.net. (Because the UK mirror is slower.)

Try the following (it's where I am learning a great deal):

http://www.zend.com/zend/art/parsing.php (Very useful examples)
http://us2.php.net/manual/en/ref.xml.php (Found the above link the comments on this page)

You want mbstring which supports, among other things, the UTF-8 incarnation of the Unicode standard.

Indeed. I've been working with MySQL for a long time now, and while learning Postgres would be fairly easy for me (I know various DBMSes already and besides, learning a new one is just learning its special cases once you know SQL in general), the problem is actually finding hosts that use it. I try to keep applications that I write for release as modular as possible, including the database type (take a look at Pear::DB if you're using PHP), but MySQL support is always the priority simply because it's what the vast majority of people use.

error_reporting(E_ALL); helps a lot

Admittedly, I didn't RTFA, but 'goto' is almost definite to be included in PHP6 upon release.

The name "goto" is misleading, and often associated with BAD THINGS(tm). Because our proposed solution is not a real GOTO construct, we will instead reuse the "break" keyword, and extend it with a static label.

It's discussed.

http://www.php.net/~derick/meeting-notes.html#name -spaces

There isn't really anything to hate about the PHP license. It's free to use for business or personal use, and it's distributed in source form so you can poke at the internals. You're allowed to modify it and even redistribute it. I don't see what the problem is here. You're whining about nothing, I suggest you find some cheese to go with it.

Since jero.net already seems to be /.ed...

Taking a look at PHP 6

While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.

Unicode support

When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file, you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.

The big cleanup

PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.

Im, of course, talking about the register_globals , magic_quotes and safe_mode functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.

In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.

Alternative PHP Cache

Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.

OO Functionality

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial about namespaces quite useful.

Changes to the extensions

PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.

Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used

Since jero.net already seems to be /.ed...

Taking a look at PHP 6

While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.

Unicode support

When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file, you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.

The big cleanup

PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.

Im, of course, talking about the register_globals , magic_quotes and safe_mode functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.

In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.

Alternative PHP Cache

Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.

OO Functionality

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial about namespaces quite useful.

Changes to the extensions

PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.

Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used

Since jero.net already seems to be /.ed...

Taking a look at PHP 6

While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.

Unicode support

When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file, you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.

The big cleanup

PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.

Im, of course, talking about the register_globals , magic_quotes and safe_mode functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.

In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.

Alternative PHP Cache

Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.

OO Functionality

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial about namespaces quite useful.

Changes to the extensions

PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.

Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used

Since jero.net already seems to be /.ed...

Taking a look at PHP 6

While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.

Unicode support

When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file, you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.

The big cleanup

PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.

Im, of course, talking about the register_globals , magic_quotes and safe_mode functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.

In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.

Alternative PHP Cache

Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.

OO Functionality

The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial about namespaces quite useful.

Changes to the extensions

PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.

Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used

I also made the mistake of building a website with it. That was a terrible decision on my part. I've finally replaced it by rolling my own using Smarty, wfCart, and paypal_ipn.

Most the functions work one way, but there are just enough that reverse target parameters that you can never be quite sure you got it right.

You can look it up, you know. Very easy way to be sure. I usually have a browser tab open to TFM. Quite handy.

PHP inherits functions from a rich variety of sources. Those sources often have differing parameter orders. No big deal. (But then I'm a C guy from back in the day, got used to having to look up things like memcpy vs bcopy.)

Don't forget PDO in v5.1. It's a _GREAT_ feature, really simplifying database functionality for PostgreSQL, MySQL and others. The calls and itterators are really smart, and syntax is golden. It makes heavy use of exceptions. See http://www.php.net/pdo for more details and examples.

A response in the Web enviroment shouldn't take longer than ~3 seconds and most of that is just transmitting data. So your script runs for less than a second - and you want thread for that short time? The only thing that needs to be async in PHP is IO and you can use http://pecl.php.net/package/event for that.

Maybe you're used to programm in a specific way. But PHP won't be the language for that. I don't unterstand you argument for scaling, but maybe that's because of you not unterstanding scaling.

PHP5 uses MySQLi which has both a procedural and object-oriented interface, and it supports features from MySQL 4 and 5 such as transactions and stored procedures. The old MySQL libraries are technically for MySQL 3, so there's not much need for those anymore.

Then there are PHP Data Objects for a unified database interface (although it is a bit primitive when compared to PEAR DB and other DBIs).

PHP5 uses MySQLi which has both a procedural and object-oriented interface, and it supports features from MySQL 4 and 5 such as transactions and stored procedures. The old MySQL libraries are technically for MySQL 3, so there's not much need for those anymore.

Then there are PHP Data Objects for a unified database interface (although it is a bit primitive when compared to PEAR DB and other DBIs).

PHP5 uses MySQLi which has both a procedural and object-oriented interface, and it supports features from MySQL 4 and 5 such as transactions and stored procedures. The old MySQL libraries are technically for MySQL 3, so there's not much need for those anymore.

Then there are PHP Data Objects for a unified database interface (although it is a bit primitive when compared to PEAR DB and other DBIs).

There is an implementation of this idea (and more) in PEAR's DB_DataObject package:

http://pear.php.net/manual/en/package.database.db- dataobject.php

This article is all nice and well, but last time i checked there were PLENTY of OO DB connection classes in php. Why does this article decide to example off of that? http://pear.php.net/ has a fine db class, and as far as i know php 5 has a whole new set of connection objects, specifically crafted for each type of database. If your going to show 'new dynamics of php5' at least choose somthing that has'nt been done already so we can make real sense of it.

From php.net

But how come the New York PHP Conference logo looks just the like CDPHP's logo?

Yes CVS or Subversion is a good choice.

If you are interested in PHP coding it is the best to get stick with some existing PHP platform or system that already solved this or is going to solve it: Zend collaboration or PEAR
or... any existing CMS like Mamboo or...

I was maintaining my own libraries for years but I found it very difficult and ineffective because of the way I did it.

Every project was slightly different so I ended up reinventing (or breaking and fixing and enhancing) the wheel over and over...

Sure, the low-level functions can be reused easily without any changes but higher
level functions that has more complicated logic are difficult to reuse in different systems which are often based
on different processing logic (and went through different historical evolution)...

I realized that maintaining separated snippets of libraries is very ineffective so I decided to write Elixon Platform
which helps me to organize existing libraries and still keep the same intercommunication and logic and
coding style intact because it is still one Platform.

So my advise is: try to avoid looking at the libraries as at "stand-alone independent snippets" and try to integrate
all libraries under one umbrella while keeping them modular and as much independent as possible.

Since you mentioned PHP: take a look at the PEAR project, the organization of its library and the structure of its classes. Lots of smart code reuse there.

Good luck,
JP

You should do something like:

  $db->query ('SELECT * FROM pages WHERE page = ?', array ($_GET['page']));

PEAR::DB makes it possible to query databases from PHP without going insane.

http://www.php.net/manual/en/function.session-cach e-expire.php

Disable the PHP easter egg:

http://www.php.net/?=PHPE9568F36-D428-11d2-A769-00 AA001ACF42

It's not clear from your comment, but you are aware that file-based sessions are just the default in PHP, aren't you? You can implement everything you say within the existing PHP framework by using session_set_save_handler(). You don't have to drop PHP's session handling entirely, just implement your own de/serialisation functions and give them to PHP.

Yes. I've read it on the Hungarian Unix Portal. (you could obviously try googling too, if you don't speak hungarian. :]) A quick googling turned up this aswell.

That was the reference and proof. Obviously spammers not only know about this technique but use it to spam effectively and quite anonymously (spammers use windows zombies to flood vulnerable php forms). With a smart google query you could turn up hundreds of vulnerable php forms. But you shouldn't look so suprised. PHP is a security mess, even the Secure PHP effort is basically offering workarounds only. Serious users should avoid PHP and use Perl, Python or Ruby.

You can also use the ADODB to make database code more portable, or if you have a new enough version of PHP, PDO.

PHP out of the box is, indeed, "too close to the HTML", and PHP and HTML code are often interlarded together in the same file. This is fine for quick & dirty applications, but for anything even a little bit more advanced, Smarty templating -- http://smarty.php.net/ -- is a very elegant solution. Logic and layout can be completely separated. It also simplifies the dev cycle: create simple, interim PHP files that just declare arrays and variables stuffed with fake data and have your HTML/front end coders working with that, then when your dev work and db stuff is done the switchover can be seamless if you've done it right.

Skal Tura said:
"I still don't see much of a benefit on doing that, you mean that i don't need to instantiate the class to be an object? (ie. no $something = new Class;)"

No, I may have expressed myself wrongly or it is just still unclear to you.

Actually if you call Object::someMethod(); you are just calling the method that is defined as static for the class (even if in PHP4 for example, there is no static).

In that static method, you won't be able to use thing like $this, because you are not working on an instance of the object ($this being a pointer to the instance of the object), you are just calling it.

So if you have a function that doesn't do anything on the object itself, but you want it associated with your class definition, you may use it that way.

Example that I saw is like when you want to retrieve a list of Something.

You will do:

Something::findAll(); // return an array with the list of all Something
Something::findById($id); // return an instance of Something or null if not found
etc.

You could as well code a function:

find_all_something(); or something_find_all(); amd it will be the same.

Some more code (unfortunaly it doesn't look as right on slashdot preview, but you may copy it in some editor to read it better)

class Something
{
    var $id;
    var $name;
    var $description;
. /* setter and getter, those work on the instance directly. */
    function setId($id) { ... }
    function getId() { ... }
    function setName($id) { ... }
    function getName() { ... }
    function setDescription($id) { ... }
    function getDescription() { ... }
. /* to save or delete (i.e. destroy) your object */
    function save() { ... }
    function delete() { ... }
. /* to retrive something (i.e. from database), I already talked about this */
    function findAll() { ... }
    function findById($id) { ... }
    function findByIds($ids) { ... }
. /* if you want to sort a list of something, you can use that function
    * to help sort the result.
    * example: usort($list_of_something, array("Something", "compareByName"));
    * see: http://ca.php.net/manual/en/function.usort.php
    */
    function compareByName($a, $b) { ... }
}

So you may work it out like this: /* $list_of_something = array(); */
$list_of_something = Something::findByIds(array(3,10,14)); // retrieve Something with id 3, 10 and 14
$list_of_something[] = Something::findById(126); // add Something with id 126

usort($list_of_something, array("Something", "compareByName")); // will sort the list by the name of Something.

Well here you don't use Something::compareByName() ... but it is used staticly.

When I write this, I feel it is clean (of course it is a pretty simple case too). But I think those can be useful and clean way to use static method for a class.

Hope that help ;-)

Skal Tura said:
"WASP seems far from simple, let's take this example:
Request::getParameter('Add') != null
wtf? Why can't one do $_POST['Add'] != null?
What format even is Something::Something ??"

------------

Well Something::Something is simply the syntax to access a static function of a class. It is simple.

See http://www.php.net/manual/en/keyword.paamayim-neku dotayim.php

Either I misunderstood, but it is not like it is one of the most obscure thing in PHP to know that one.

Global variables are not harmful at all. The misuse of global variables is. This is a very common misconception shared by most new PHP programmers who read the wrong material on the web, or listen to other inexperienced PHP programmers for security advice.

Now, I'm going to take a leap here, and assume you're actually talking about the register_globals directive, and not global variables in general. From the site: [..]This page will explain how one can write insecure code with this directive but keep in mind that the directive itself isn't insecure but rather it's the misuse of it[..] - the whole reason for register_globals was because the creators of PHP knew lots of bad programmers were going to use PHP to do silly things. In hindsight, it was probably not the best move. A language should not go to great lengths to shelter it's users.

Any bad programmer can write bad code in any language. The thing to remember is that it's a bad carpenter who blames his hammer for not automaticly avoiding his thumb during use.

Let me get this right..
You have a low-enough UID to supposedly be somewhat knowledgeable, yet you advocate writing frameworks and not marrying the code to the framework..?
Then why the hell are you mixing the View in with the Model (and most likely Controller too?)

Honestly, it's people like you who give PHP a really bad name.
Any sane person would AT LEAST be using a templating system like Smarty.

Languages like Ruby need a framework because:

1. There are few web-centric functions available
2. They run as persistent processes (via FastCGI)
3. There is an obvious need for model-view-controller

No wonder it needed a re-write, its outdated and crufty, compared to more modern scripting languages. Perl has lost its identity, razzle and dazzle from then it was first introduced..

With hacked on OO, CGI that is painful - there is little reason to revisit, because looking at Perl 5, and Perl 6 - they look completely different.

Thank god for new things like this to keep one amused.

My latest web development platform, is Ruby on Rails. I was a sworn Perl, PHP guru until I started using this puppy - its absolutely amazing. Everything else is just too tiring..

Oh my god, let the flame wars begin!

Oh come on, face it: reference were thrown into Perl as an afterthought, and they're kludgy, badly designed, overly complex, absolutely horrible and unnecessarily subtle. PHP is crippled with the exact same problem, because it's a cargo-cult programming language, which tries to ape the superficial aspects of Perl and C++, instead of having a clean well thought out design.

References in Perl and PHP disingenuously try to LOOK like C++ references by using the same punctuation character (thus misleading C++ programmers into thinking they understand what's going on), but they're each totally different ad-hoc kludges thrown in long after the base language was designed. At least C++ references are well defined in terms of pointers, so there aren't so many horrible edge cases that cause the interpreter to core dump:

Bug #30674: Unexpected results and core dump with recursive references serializing
Bug #32660 Assignment by reference causes crash when field access is overloaded (__get)
Bug #22237 PHP crashes when class references property using variable variable
Bug #34277 array_filter() crashes with references and objects
Bug #22510 Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
Bug #16387 PHP loop when using reference to an object in an object (both in session)
Bug #34137 assigning array element by reference causes binary mess
Bug #32179 xmlrpc_encode() Segmentation fault with recursive reference
Bug #31525 object reference being dropped. $this getting lost.
PHP: References Explained:

Since references are more like hardlinks than pointers, it is not possible to change a reference to an object by using that same reference. For example: The following WILL NOT WORK as expected and may even crash the PHP interpreter:
$object =& $object->getNext();
However, by changing the previous statement to use a temporary reference, this WILL WORK:
$temp =& $object;
$object =& $temp->getNext();

Face the reality: This is just the tip if the iceberg, a few samples of the many hard crashes caused by the half baked implementation of references in PHP, because it's such a horribly designed and deeply flawed language. Those crashes are actually caused by bugs in the programming language itself, even though the programmers were following the rules -- but there's no way of counting the zillions of actual PHP and Perl programs that crash or produce incorrect results because the people who wrote them don't understand the subtleties and limitations of PHP and Perl references.

References in Perl and PHP are unlike references in any other reasonably designed programming language: they totally suck. They're extremely hard to understand, but sometimes they still crash the interpreter, even if you do understand them perfectly and use them correctly.

-Don

Oh come on, face it: reference were thrown into Perl as an afterthought, and they're kludgy, badly designed, overly complex, absolutely horrible and unnecessarily subtle. PHP is crippled with the exact same problem, because it's a cargo-cult programming language, which tries to ape the superficial aspects of Perl and C++, instead of having a clean well thought out design.

References in Perl and PHP disingenuously try to LOOK like C++ references by using the same punctuation character (thus misleading C++ programmers into thinking they understand what's going on), but they're each totally different ad-hoc kludges thrown in long after the base language was designed. At least C++ references are well defined in terms of pointers, so there aren't so many horrible edge cases that cause the interpreter to core dump:

Bug #30674: Unexpected results and core dump with recursive references serializing
Bug #32660 Assignment by reference causes crash when field access is overloaded (__get)
Bug #22237 PHP crashes when class references property using variable variable
Bug #34277 array_filter() crashes with references and objects
Bug #22510 Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
Bug #16387 PHP loop when using reference to an object in an object (both in session)
Bug #34137 assigning array element by reference causes binary mess
Bug #32179 xmlrpc_encode() Segmentation fault with recursive reference
Bug #31525 object reference being dropped. $this getting lost.
PHP: References Explained:

Since references are more like hardlinks than pointers, it is not possible to change a reference to an object by using that same reference. For example: The following WILL NOT WORK as expected and may even crash the PHP interpreter:
$object =& $object->getNext();
However, by changing the previous statement to use a temporary reference, this WILL WORK:
$temp =& $object;
$object =& $temp->getNext();

Face the reality: This is just the tip if the iceberg, a few samples of the many hard crashes caused by the half baked implementation of references in PHP, because it's such a horribly designed and deeply flawed language. Those crashes are actually caused by bugs in the programming language itself, even though the programmers were following the rules -- but there's no way of counting the zillions of actual PHP and Perl programs that crash or produce incorrect results because the people who wrote them don't understand the subtleties and limitations of PHP and Perl references.

References in Perl and PHP are unlike references in any other reasonably designed programming language: they totally suck. They're extremely hard to understand, but sometimes they still crash the interpreter, even if you do understand them perfectly and use them correctly.

-Don

Oh come on, face it: reference were thrown into Perl as an afterthought, and they're kludgy, badly designed, overly complex, absolutely horrible and unnecessarily subtle. PHP is crippled with the exact same problem, because it's a cargo-cult programming language, which tries to ape the superficial aspects of Perl and C++, instead of having a clean well thought out design.

References in Perl and PHP disingenuously try to LOOK like C++ references by using the same punctuation character (thus misleading C++ programmers into thinking they understand what's going on), but they're each totally different ad-hoc kludges thrown in long after the base language was designed. At least C++ references are well defined in terms of pointers, so there aren't so many horrible edge cases that cause the interpreter to core dump:

Bug #30674: Unexpected results and core dump with recursive references serializing
Bug #32660 Assignment by reference causes crash when field access is overloaded (__get)
Bug #22237 PHP crashes when class references property using variable variable
Bug #34277 array_filter() crashes with references and objects
Bug #22510 Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
Bug #16387 PHP loop when using reference to an object in an object (both in session)
Bug #34137 assigning array element by reference causes binary mess
Bug #32179 xmlrpc_encode() Segmentation fault with recursive reference
Bug #31525 object reference being dropped. $this getting lost.
PHP: References Explained:

Since references are more like hardlinks than pointers, it is not possible to change a reference to an object by using that same reference. For example: The following WILL NOT WORK as expected and may even crash the PHP interpreter:
$object =& $object->getNext();
However, by changing the previous statement to use a temporary reference, this WILL WORK:
$temp =& $object;
$object =& $temp->getNext();

Face the reality: This is just the tip if the iceberg, a few samples of the many hard crashes caused by the half baked implementation of references in PHP, because it's such a horribly designed and deeply flawed language. Those crashes are actually caused by bugs in the programming language itself, even though the programmers were following the rules -- but there's no way of counting the zillions of actual PHP and Perl programs that crash or produce incorrect results because the people who wrote them don't understand the subtleties and limitations of PHP and Perl references.

References in Perl and PHP are unlike references in any other reasonably designed programming language: they totally suck. They're extremely hard to understand, but sometimes they still crash the interpreter, even if you do understand them perfectly and use them correctly.

-Don

Oh come on, face it: reference were thrown into Perl as an afterthought, and they're kludgy, badly designed, overly complex, absolutely horrible and unnecessarily subtle. PHP is crippled with the exact same problem, because it's a cargo-cult programming language, which tries to ape the superficial aspects of Perl and C++, instead of having a clean well thought out design.

References in Perl and PHP disingenuously try to LOOK like C++ references by using the same punctuation character (thus misleading C++ programmers into thinking they understand what's going on), but they're each totally different ad-hoc kludges thrown in long after the base language was designed. At least C++ references are well defined in terms of pointers, so there aren't so many horrible edge cases that cause the interpreter to core dump:

Bug #30674: Unexpected results and core dump with recursive references serializing
Bug #32660 Assignment by reference causes crash when field access is overloaded (__get)
Bug #22237 PHP crashes when class references property using variable variable
Bug #34277 array_filter() crashes with references and objects
Bug #22510 Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
Bug #16387 PHP loop when using reference to an object in an object (both in session)
Bug #34137 assigning array element by reference causes binary mess
Bug #32179 xmlrpc_encode() Segmentation fault with recursive reference
Bug #31525 object reference being dropped. $this getting lost.
PHP: References Explained:

Since references are more like hardlinks than pointers, it is not possible to change a reference to an object by using that same reference. For example: The following WILL NOT WORK as expected and may even crash the PHP interpreter:
$object =& $object->getNext();
However, by changing the previous statement to use a temporary reference, this WILL WORK:
$temp =& $object;
$object =& $temp->getNext();

Face the reality: This is just the tip if the iceberg, a few samples of the many hard crashes caused by the half baked implementation of references in PHP, because it's such a horribly designed and deeply flawed language. Those crashes are actually caused by bugs in the programming language itself, even though the programmers were following the rules -- but there's no way of counting the zillions of actual PHP and Perl programs that crash or produce incorrect results because the people who wrote them don't understand the subtleties and limitations of PHP and Perl references.

References in Perl and PHP are unlike references in any other reasonably designed programming language: they totally suck. They're extremely hard to understand, but sometimes they still crash the interpreter, even if you do understand them perfectly and use them correctly.

-Don

Oh come on, face it: reference were thrown into Perl as an afterthought, and they're kludgy, badly designed, overly complex, absolutely horrible and unnecessarily subtle. PHP is crippled with the exact same problem, because it's a cargo-cult programming language, which tries to ape the superficial aspects of Perl and C++, instead of having a clean well thought out design.

References in Perl and PHP disingenuously try to LOOK like C++ references by using the same punctuation character (thus misleading C++ programmers into thinking they understand what's going on), but they're each totally different ad-hoc kludges thrown in long after the base language was designed. At least C++ references are well defined in terms of pointers, so there aren't so many horrible edge cases that cause the interpreter to core dump:

Bug #30674: Unexpected results and core dump with recursive references serializing
Bug #32660 Assignment by reference causes crash when field access is overloaded (__get)
Bug #22237 PHP crashes when class references property using variable variable
Bug #34277 array_filter() crashes with references and objects
Bug #22510 Zend Engine crashes calling FREE_ZVAL from zend_assign_to_variable_reference
Bug #16387 PHP loop when using reference to an object in an object (both in session)
Bug #34137 assigning array element by reference causes binary mess
Bug #32179 xmlrpc_encode() Segmentation fault with recursive reference
Bug #31525 object reference being dropped. $this getting lost.
PHP: References Explained:

Since references are more like hardlinks than pointers, it is not possible to change a reference to an object by using that same reference. For example: The following WILL NOT WORK as expected and may even crash the PHP interpreter:
$object =& $object->getNext();
However, by changing the previous statement to use a temporary reference, this WILL WORK:
$temp =& $object;
$object =& $temp->getNext();

Face the reality: This is just the tip if the iceberg, a few samples of the many hard crashes caused by the half baked implementation of references in PHP, because it's such a horribly designed and deeply flawed language. Those crashes are actually caused by bugs in the programming language itself, even though the programmers were following the rules -- but there's no way of counting the zillions of actual PHP and Perl programs that crash or produce incorrect results because the people who wrote them don't understand the subtleties and limitations of PHP and Perl references.

References in Perl and PHP are unlike references in any other reasonably designed programming language: they totally suck. They're extremely hard to understand, but sometimes they still crash the interpreter, even if you do understand them perfectly and use them correctly.

-Don