Even with the release of PHP 5.3 looming closer and closer on the horizon, there's a few things that are still being worked through - one of which is the much touted namespace support. Elizabeth Smith has posted a few of the issues that she's having with how they're being implemented, four and a half of them, to be exact.

The first thing to clarify is that I like the new implementation overall, it's fairly light and although it isn't really namespacing or packaging in any sense of the word, the best way to describe it is aliasing, it does help keep code easy to use. In fact I have a couple of projects and even a PHP extension that's all namespaced code.

Her list of five (four and a half) things are:

• multiple namespaces in a file
• you can't have ANYTHING before the namespace statement but an opening <?php tag
• The autoload and resolution paths
• Functions in namespaces
• No use * and three million use statements (this is the one with the workaround - class_alias)

Lukas Smith has asked a question of the community with the release of PHP 5.3 coming nearer and nearer - who out there is using namespaces already?

As I said in my last post we are not yet sure if we need to make some changes to namespaces before we can move from alpha to beta in the current 5.3.0 release cycle. What I did not ask for explicitly is feedback from people that have already started developing code with namespaces. These people are likely the best source of feedback on the current state of namespaces and if the proposed changes to namespaces would be useful or not

He mentions that the Doctrine project is already playing with them and, apparently, some of his commentors - one using them on a library in development, porting over XJConf to use them and other various projects.

On the Sanisoft blog today Tarique Sani has posted about a method for using the CakePHP framework without a database to back it up.

We recently programmed a CakePHP app which relies solely on remote server talking Saleforce API for all data operations. The first challenge that we faced was how to prevent CakePHP from insisting on a database connection. The solution was simple enough and I never gave it much thought till the same question was brought up by more than one person on the CakePHP list. The solution involves creating a minimal dbo source file.

It's a simple three step process to follow - making the dbo source file, set it up as the default driver and tell CakePHP to $useTable = false.

A new tutorial has been posted to php|architects C7Y community site looking at some practical uses of the PHP tokenizer to work with your source.

In this article we take a look at the PHP tokenizer and its potential at analyzing and processing PHP source code. We will build several working examples, which you can start using and extending for your own purposes.

The author, Stan Vassilev, explains what the tokenizer is for, how it parses the code (via a lexer) and how to get at the tokens that are created. He uses the token_get_all and token_name functions to get the information and creates a wrapper class around them to strip whitespace and comments.

After hearing Stefan Priebsch's talk at this year's Dutch PHP Conference, something occurred to Derick Rethans - there was a small sort of issue with using namespaces and possible future PHP's own namespace.

One of the things that came up is the conflicts that can arise with internal classes. In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working

He offers a simple solution that can prevent this sort of conflict for the future - defining your "use" and then creating a new instance of the namespace into a variable instead of just an "as".

The Developer Tutorials blog has posted their five reasons why they think you should be including PHP in your development.

Sure, it isn't perfect. It has its problems; from professionalism to consistency and even versioning. Still, it's a fantastic language for web development; it's efficient, scalable and, when used appropriately, effective. Read on for five reasons you should be using PHP for web development.

They break it up into:

• Deployment
• Functionality
• Infrastructure
• Speed
• Resources

On PHPBuilder.com today there's this new tutorial for those out there at the most basic level of PHP development looking to get up to speed on what PHP is and what makes it one of the most popular web scripting languages out there.

PHP (or Personal HomePage Tools) was created by Rasmus Lerdorf over three years ago to track visitors to his homepage. PHP has since evolved into a powerful server-side markup language with syntax that resembles a mix between Perl and C.

They cover all of the key questions - what is PHP, why use it and a simple explanation of a basic script (outputting the date) as well as links to other external resources where you can get more information.

According to I-nfotech, there's ten projects that every PHP developer out there just can't live without:

As a php web developer, you should know that php is probably the language that has the biggest code repository. So no matter what module you want to include in your project there should be an open source solution. [...] Anyway, after many years as a web developer, I've compiled a list of php classes that can be easily integrated in any project and I am regularly use.

He has it broken up into the ten different categories including "sending emails", "user manipulation", "fetching RSS feeds" and "grabbing remote content". Some of his choices are things native to PHP (like the mail function) but others are external classes like the Magpie RSS package.

David Coaller has posted about a major change in the way namespaces will be implemented in the upcoming PHP 5.3 release - a change from using "import" to "use" for including a namespace in your code.

PHP Namespaces are no longer using the "import" keyword, this has been replaced to the keyword "use". Quite simple he ? There are a few reasons behind that move, but let's all drop the political reasons and say at least that many many projects in the open source world do use the import() function to do all sorts of weird imports, and it's just simpler to use "use".

He also links to the original email from Stanislav about the reasoning behind change. He's also updated his previous post to reflect the change.

Josh Sharp has posted a new article to his blog advocating something that there's still a lot of controversy around in the PHP community - frameworks (when to use them and when to not).

PHP's ease of use is also its downfall. Because there are less restrictions on the structure of the code you write, it's much easier to write bad code. But there is a solution: use a framework. [...] Of course, if you're not taken with any of the packages above you can also write your own framework, which I've done and will talk about in the next few posts. But for now, let's have a look at the common benefits of a framework.

He's broken it out to talk about the usual framework structure, MVC and how a framework can enforce good code standards. He also mentions some happy side benefits of their use including making for "pretty URLs" and the helpers that most of the frameworks come with.