Slashdot Mirror

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

Most programmes written in C and C++ crash due to buffer overflows, which frequently lead to running unsigned code. /JOKE

Well, I'm glad I use PHP so that I don't have any of those nasty, security problems! /SERIOUSLY

It's kinda funny - things like buffer overflows just don't really happen in PHP (at least, in the PHP code, a few have been found in the C code in which PHP itself is written) but there are still a slew of security issues. A few I end up thinking about most:

1) SQL-Injection. This can be handled by exclusive use of prepared statements.
2) Shell injection. This is best handled by a shell command wrapper, with arguments passed in via an array.
3) Cross-site scripting, HTML injection attacks. I don't yet have a good way to handle this, other than manual calls to strip_tags(); I wish there was a way to shotgun fix this problem.
4) Uninitalized variables - this is a matter of structuring the code right, so that they just don't happen. It'd be nice if there was an "init" function that, when not used, would at least trigger a warning error if you accessed a variable that was previously unitialized. EG: init($var, array());

Anybody else care to comment?

PHP relies upon the discrimination and knowledge of the author to be secure; it takes no responsibility for encouraging or facilitating good practice.

That's like saying my car is insecure, because I have to physically lock it myself. Is Python inherently more secure? Yeah probably. But I get sick of people speaking of PHP as if it's some sort of gaping security hole when they should obviously be learning to write better code. Using mysql_real_escape_string() is far from a complex procedure.

I would have thought it's a good idea to turn off the display of PHP errors and make sure log_errors is on, as well.

Not only is the site totally b0rked, but so are the caches because of this.

Yeah, it's too bad PHP doesn't support some sort of database abstraction layer. ;-)

Realistically, if you design an application from the start with even just a little bit of, well. . . design, and consideration for portability and future growth, database independance is not very difficult.

Unfortunately, it's been my experience that most people don't really think beyond the next few hours when they're coding, which means that making things better later on is a huge chore.

Yeah, it would be great if PHP had some PostgreSQL functions.

Reality has no precedent around this place, or in much of the OSS community.

That's right. No reality.

Like Apache is not a reality, with its 75% market share.

Like PHP's popularity as the #1 web scripting language?

Come on, man!

Personal Home Page was the original I believe. So, even more depth to LAMP. http://us3.php.net/history

PHP programming is becomming about the libraries. Smartyhttp://smarty.php.net/ - a template library makes putting coherent websites together easier. Although it doesn't do anything for the database part of the site, its one less thing to worry about.

  PEAR confused me and I was programming before it so I have my own libraries. The php web documentation is excellent.

although the java studio creator is now free, and seems like an amazing tool, its not enough to get me away from php
http://developers.sun.com/prodtech/javatools/jscre ator/reference/quicktour/2/flash/index.html

I think your comment is especially true when it comes to PHP and MySQL. The websites for PHP and MySQL have a massive amount of information and documentation which could replace several books written for them already. The comments in their documentation on the two websites posted by users is even more useful:

MySQL documentation
PHP documentation

Having learned the things I'm about to list in a less-preferred order, I recommend learning in this order. Some may overlap a bit.

First, learn a lot more about HTML than you know. Learn how to create the correct structure in your sites, and try to avoid excessive tags such as tables and divs. Use page headers (h1, h2,...) and paragraph (p) tags and avoid line breaks (br) unless you're actually attempting to do a line break and not just creating space. Here's a good article to read: http://brainstormsandraves.com/articles/semantics/ structure/.

Learn XHTML, and while you're at it, learn a little bit about basic XML and how it works. W3Schools has a good introduction. XHTML, XML. Don't go too far just yet with XML.

While you're learning XHTML, you'll inevitably encounter CSS. The W3C has plenty of links to articles. Make absolutely sure that you learn CSS, it is the pivot point of learning truly professional looking web development (even if you don't want to do it professionally).

Eventually, you'll need to either build your own system for a blog (as you mentioned you'd like to do), or use a blog management system such as Wordpress. If you choose to do it yourself, you need to learn 2 things. SQL and PHP. I recommend using MySQL (an implementation of SQL) because it's free. Most webhosts will support PHP and MySQL as well, so it's more widespread. W3Schools has the easiest introduction to SQL that I've seen. PHP.net has a complete PHP reference. Make sure to check out the mysql section, because that's what you'll be using most.

Scripting comes next. DevGuru has a pretty good, although incomplete reference for basic JavaScript. Basically, just do a search on Google for Javascript reference and you'll pretty much be able to find anything you want. As you get more advanced, try to understand more complex JavaScript such as the Prototype library, among others.

At this point, you'll have a firm grip on web development. Go back and refresh your skills with XHTML and CSS and you'll find out how much you still have left to learn.

There are many other things to learn about web development, specifically if you want to do web programming and application development. That's a whole other can of worms though.

The way I do things, there are several components to Web Development:

Document markup and design:
HTML: Used for document markup only!
CSS: Used to solve most display requirements

Content management / functionality:
Javascript: Client side DHTML (when you DONT want to refresh the page)
PHP: database interaction, web forms, etc.

The CSS links CanSpice points to are excellent resources. I think you should start there, regardless of wanting to learn a web programming language. Knowing CSS will benefit you to:

+ Start on the right path with web standards (as opposed to old HTML 4 sins that many webmasters commit to this day). HTML is NOT for display / design purposes, only for document markup.
+ Cross-browser functionality
+ Less code (you can usually do a lot more with a little css, compared to html)
+ Separation of design and code. You can keep all your css in an external stylesheet than can be updated independently of the site code.

As far as web programming, you basically have two sides:

1. Javascript
It is extremely useful for its DHTML capabilities. You can instantly move html elements around on a page and do some pretty powerful stuff with this. People hate it when they have to refresh a page for something as simple as sorting a table. This is where Javascript shines. Get started by learning the DOM (document object model). Keep in mind that each browser implements this model a little differently so you can consult each browser's documentation.

http://msdn.microsoft.com/library/default.asp?url= /workshop/author/dhtml/dhtml.asp (IE)
http://www.mozilla.org/docs/dom/domref/dom_shortIX .html (mozilla)
http://www.w3.org/TR/DOM-Level-2-Core/core.html (safari implements this)
www.brainjar.com (great for DHTML as well as CSS)

(by no means a complete list but you get the picture)

2. PHP.
YMMV, but I have found this to be one of the easiest languages to learn. Other contenders in this category include: ASP, ASP.NET, C#, Perl, ColdFusion just to name a few. PHP has a very low effort to learn and there are tons of resources on the web to help you. The Microsoft languages (.NET stuff) are pretty powerful too, but you mentioned this is mostly for hobby reasons so I would recommend going with something with an open license like PHP. ColdFusion is also extremely easy to learn, but your host may not support it (and you may not want to have to purchase the Macromedia IDE for it).

Some great PHP resources:
http://www.php.net/manual/en/
www.w3schools.com

Good luck!

I sincerely wish the developers of PHP put more of a focus on security

Well they've given us safe mode on by default to limit dangerous functions.
They've turned on magic quotes by default to stop SQL injection.
They've turned off register globals by default to stop namespace problems.

They are moving in the right direction. The main problem is PHP is fairly easy to get into but leaves enough space for users to hang themselves. This doesn't happen so much with the drag n drop style development of ASP as developers don't write so much of the code there so aren't falling over basic problems with parsing GET/POST variables and the like.

I sincerely wish the developers of PHP put more of a focus on security

Well they've given us safe mode on by default to limit dangerous functions.
They've turned on magic quotes by default to stop SQL injection.
They've turned off register globals by default to stop namespace problems.

They are moving in the right direction. The main problem is PHP is fairly easy to get into but leaves enough space for users to hang themselves. This doesn't happen so much with the drag n drop style development of ASP as developers don't write so much of the code there so aren't falling over basic problems with parsing GET/POST variables and the like.

I sincerely wish the developers of PHP put more of a focus on security

Well they've given us safe mode on by default to limit dangerous functions.
They've turned on magic quotes by default to stop SQL injection.
They've turned off register globals by default to stop namespace problems.

They are moving in the right direction. The main problem is PHP is fairly easy to get into but leaves enough space for users to hang themselves. This doesn't happen so much with the drag n drop style development of ASP as developers don't write so much of the code there so aren't falling over basic problems with parsing GET/POST variables and the like.

<?php
phpinfo();
$_GET = "Not what I put on the URL line";
function getit()
{
        echo "<br>{$_GET}</br>";
}
getit();
?>

Then you can set the error reporting level to E_ALL:

error_reporting( E_ALL ); // for run-time

RTM: http://www.php.net/error_reporting

So, you think strong typing and heavy compilation (with all the attendant futzing around with silly little converter classes and twiddling your thumbs while the whole lot grinds through the compiler again) are necessary for OO-in-business-scenarios? Interesting. Can't say I agree though. Highly typed languages are overrated (and PHP is definitely not best-of-breed in the light-typing end) and compilation to native code is not so useful as you might think; there's usually a better level of abstraction to use as a compilation target (i.e. which allows for very fast compilation while providing decent speed), assuming you're not writing some real CPU-heavy code like image manipulators. But then most web-apps aren't about that; they're "parse the input, diddle with the DB, possibly contact some other service, format the output". All the scripting languages are good choices for that sort of thing, though some are better than others for mundane reasons. Reasons like "the natural way to write code is the secure way to write code!" But you take your pick according to your personal preferences (or sometimes those of your boss, alas.)

The Releases page doesn't show the PECL download. Nor does the downloads page. I hope this is just an oversight and will eventually be corrected.

The Releases page doesn't show the PECL download. Nor does the downloads page. I hope this is just an oversight and will eventually be corrected.

PDO is a free solution to most of these. It's slated to go stable this weekend.

IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
PDO_ODBC, Zend Core for IBM

Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
PDO_OCI, Zend Core for Oracle

ADABAS, also known as SAP DB, is now also FOSS
This one, I know very little about..

Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
PDO_Firebird

I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
PDO_DBLIB

S

PDO is a free solution to most of these. It's slated to go stable this weekend.

IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
PDO_ODBC, Zend Core for IBM

Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
PDO_OCI, Zend Core for Oracle

ADABAS, also known as SAP DB, is now also FOSS
This one, I know very little about..

Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
PDO_Firebird

I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
PDO_DBLIB

S

PDO is a free solution to most of these. It's slated to go stable this weekend.

IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
PDO_ODBC, Zend Core for IBM

Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
PDO_OCI, Zend Core for Oracle

ADABAS, also known as SAP DB, is now also FOSS
This one, I know very little about..

Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
PDO_Firebird

I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
PDO_DBLIB

S

PDO is a free solution to most of these. It's slated to go stable this weekend.

IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
PDO_ODBC, Zend Core for IBM

Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
PDO_OCI, Zend Core for Oracle

ADABAS, also known as SAP DB, is now also FOSS
This one, I know very little about..

Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
PDO_Firebird

I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
PDO_DBLIB

S

PDO is a free solution to most of these. It's slated to go stable this weekend.

IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
PDO_ODBC, Zend Core for IBM

Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
PDO_OCI, Zend Core for Oracle

ADABAS, also known as SAP DB, is now also FOSS
This one, I know very little about..

Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
PDO_Firebird

I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
Correct, it's called "SQL Server 2005 Express Edition", formerly MSDE. (although, I've not tried EE2005, only MSDE -- it worked well)
PDO_DBLIB

S

PDO is the first API/extension in PHP that looks like it was designed before writing.

That's big step away from MySQL and magic_quotes mess.

Take a look at the changelog: http://www.php.net/ChangeLog-5.php#5.1.0

The lines with Added, Changed or Improved are mostly new features, the lines with Fixed are Bugfixes. 1/3 of the Changelog are therefore new features.

b4n

They are considering namespaces for PHP 6 - Read the meeting notes here:
http://www.php.net/~derick/meeting-notes.html

Issue: safe_mode is a feature in PHP that checks whether files to be opened or included have the same GID/UID as the starting script. This can cause many problems, for example if an application generates a cache file, it will do this with the user ID that belongs to the web server (usually "nobody"). As an application is usually uploaded by the user belonging to the web account (say "client") the scripts can no longer open the files that the application. The same problems happen when for example an application generates an image.

Discussion: As safe_mode is a name that gives the wrong signals as making PHP safe, we all agreed that we should remove this function. It can never be made totally safe as there will always be ways to circumvent safe_mode through libraries. This kind of functionality also better belongs in the web server or other security scheme. open_basedir is a feature that we will keep, and we will point users to this functionality in the error message that is thrown when we detect this setting on start-up.

Conclusions:

1. We remove the safe_mode feature from PHP.
2. We throw an E_CORE_ERROR when starting PHP and when we detect the safe_mode setting.

They are considering namespaces for PHP 6 - Read the meeting notes here:
http://www.php.net/~derick/meeting-notes.html

Issue: safe_mode is a feature in PHP that checks whether files to be opened or included have the same GID/UID as the starting script. This can cause many problems, for example if an application generates a cache file, it will do this with the user ID that belongs to the web server (usually "nobody"). As an application is usually uploaded by the user belonging to the web account (say "client") the scripts can no longer open the files that the application. The same problems happen when for example an application generates an image.

Discussion: As safe_mode is a name that gives the wrong signals as making PHP safe, we all agreed that we should remove this function. It can never be made totally safe as there will always be ways to circumvent safe_mode through libraries. This kind of functionality also better belongs in the web server or other security scheme. open_basedir is a feature that we will keep, and we will point users to this functionality in the error message that is thrown when we detect this setting on start-up.

Conclusions:

1. We remove the safe_mode feature from PHP.
2. We throw an E_CORE_ERROR when starting PHP and when we detect the safe_mode setting.

Strange how this bug doesn't even show up on a search, but punching it in manually brings it up, and google shows you where it is.

Apparently the ticket hasn't been touched since it was reported 16 months ago.

1. Zend hired the mmcache author, who developed things like the SOAP extension for php

2. PHP6 will have an opcode-cache (APC): http://www.php.net/~derick/meeting-notes.html#add- an-opcode-cache-to-the-distribution-apc

Why change the entire language engine (again) just to write import builtin\mysql; when you can just do $a = new mysqli; ?

Relating to this comment:
http://developers.slashdot.org/comments.pl?sid=169 325&cid=14113043

It's true that PHP suffers from various naming conventions, but namespaces might me the answer.

For PHP 6.0, does anyone know if the core developers are thinking of moving most builtin libraries into namespaces? For instance:
. . . http://ca.php.net/manual/en/function.oci-commit.ph p
could be placed in the "builtin\oci" namespace and
. . . http://ca.php.net/manual/en/function.ocicommit.php
could be placed in the "builtin\legacy\oci" namespace.

You could quickly convert all PHP5 to PHP6 simply by adding the line:
. . . import builtin\*;
to the top of every file to make all builtin functions global (the way they are in PHP5).

Apps written in PHP5 would still work without the import, but they'd get a warning (which could be switches off in the php.ini).

Relating to this comment:
http://developers.slashdot.org/comments.pl?sid=169 325&cid=14113043

It's true that PHP suffers from various naming conventions, but namespaces might me the answer.

For PHP 6.0, does anyone know if the core developers are thinking of moving most builtin libraries into namespaces? For instance:
. . . http://ca.php.net/manual/en/function.oci-commit.ph p
could be placed in the "builtin\oci" namespace and
. . . http://ca.php.net/manual/en/function.ocicommit.php
could be placed in the "builtin\legacy\oci" namespace.

You could quickly convert all PHP5 to PHP6 simply by adding the line:
. . . import builtin\*;
to the top of every file to make all builtin functions global (the way they are in PHP5).

Apps written in PHP5 would still work without the import, but they'd get a warning (which could be switches off in the php.ini).

The main reason for PHP being insecure is the huge amount of functions for "securing" form data before using it in an SQL query. It's just comical that both mysql_escape_string() and mysql_real_escape_string() exist. PHP should be purged from all of the unused and misused functions soon, or it will never be safe.

The main reason for PHP being insecure is the huge amount of functions for "securing" form data before using it in an SQL query. It's just comical that both mysql_escape_string() and mysql_real_escape_string() exist. PHP should be purged from all of the unused and misused functions soon, or it will never be safe.

I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).

I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).

I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).

They are considering namespaces for PHP 6 - Read the meeting notes here:

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

http://www.corephp.co.uk/archives/19-Prepare-for-P HP-6.html

You don't have any classes named Date, do you? It's an extremely uncommon name. Good thing we have namespaces.

http://news.php.net/php.internals/20352

Here's my chance to blab about the PVR I built myself. It's not pretty, but it runs great.
Here are the specs: Leadtek WinFast PVR 2000 TV/FM tuner card; P4 2.8E / ASUS P4P800; onboard sound; 512MB RAM; 80GB + 120GB HD; WinXP Pro.
The software I built uses: Windows Media Encoder SDK; Visual Basic 6; PHP; FireBird; Apache.
Using VB, I wrote code that goes to Zap2It and downloads 12 days worth of TV show programming and parses it into my FireBird DB. From there I have a web front end that lets you search/sort though shows. You can choose to record one show or create a rule that would record a certain show every time it's on. It also handles scheduling conflicts by prioritizing rules and doesn't record a show if it's been previously recorded.
The back end is a VB app that runs all the time and checks the FireBird DB for the next show to be recorded. When it finds one and it's time to start recording it issues a command line request to the Windows Media Encoder to start recording on channel x for x number of seconds. The size and audio/video bitrate are set using the encoder's profile editor.
The profile settings I use consist of: Windows Media Audio 9.1/Video 9; VBR quality base of 90 (usually has a video bitrate of just over 1000kbps); Video size 320 x 240. At these settings the CPU uses about 20% and 1hr worth of video is about half a GB.
I play the shows by streaming them to the Xbox running xbmc.
I also have a command line script that runs every night and deletes any shows that are older than 15 days. If I haven't watched it by then, it's not worth watching.
This setup has worked great for me for the last year. The next step would be to replace the whole setup with MythTV. I'd have the back end on my computer and the front end on the Xbox.

So it's quite funny that PHP developers are still recommending not to use apache with a threaded MPM (because of 3rd party libs not php I know). Dual core CPUs are there, the apache + php duo should be able to get top-performance from your systems to keep both on the top...

It's because of php's increasing popularity, as this page shows.

That's interesting, and I can't say I've ever heard of it. How different is this from PEAR::DB?

You should look into PDO,
database abstraction with preparation of statements et al ([code example])