Lukas Smith has a new post to his site that asks the question "what's needed to REST in Symfony 2?" In it he talks about some of the current issues surrounding REST support in Symfony (bundles) and a "call to arms" to create something better.

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed.

Some of the still outstanding issues he points out include issues with content-type and routing, dynamic content in the NelmioApi bundle, Behat context testing, JSONP support and more. He suggests gathering together a product backlog of these items and possibly making a kickstarter to fund its development.

In a new blog post on PHPClasses.org today Manuel Lemos has gathered together some of the things that PHP doesn't have (yet). Most of them are things that developers have expressed a desire for in the core and either have yet to make it into a RFC or are still just being implemented in "userland" code.

The PHP development process is still a bit frustrating. Many developers hoped that PHP had certain features but those are still missing due to several reasons. One way to see those features happen is to write code to implement the features and then submit the code to the PHP core. However that is not a guaranteed process. Even if you provide the necessary code, other developers may object to the addition of those features and the effort is wasted.

Among the things he lists as features that are desired but not implemented yet are things like:

• Aspect oriented programming
• Annotations
• Class generics
• Introspection of private variables and functions
• Named parameters

There's a summary of each of the features mentioned and in some cases links to RFCs that presented the same ideas. If you're interested in presenting your own ideas to the PHP project for inclusion, you can "demystify" the RFC process by checking out this post from Chris Jones with lots of good suggestions and the flow of how the process (usually) works.

In a new post to his site Michael Kimsal poses an interesting question about something he's noticed in several frameworks - and not just PHP ones: there seems to be a lack of authentication/authorization functionality coming bundled in.

Why do almost no web frameworks provide any default authentication/authorization functionality, with default examples of best practices for common use cases. The standard response I've gotten for years was/is "well, everyone's needs for authentication are different". No, they are not. A (very?) large majority of web applications (which is what most web frameworks are used to build), require some form of user login and authorization management, and often self-registration, dealing with lost passwords, etc.

He points out that by not having something a user can immediately deploy that's been well tested and relatively risk-free, it can introduce security holes as a developer is "left to fend for themselves". He suggests that the "not everyone's the same" mentality that seems to go with authentication/authorization isn't as valid as once thought. He does point out that both Symfony2 and Zend Framework 2 come with ACL functionality, but no common user handling. He mentions ones in a few other tools used in other languages too like Devise in Ruby, Spring Security in Grails and a membership system in ASP.NET.

Jani Hartikainen has a new post with a gotcha he came across when using typehinting in exceptions and methods.

A small gotcha I recently ran into: If you use typehinting, PHP never checks that the class your typehint specifies actually exists!

He includes simple examples that define the class type hint as some random string and PHP never throws an error for it. He also notes that it's even worse when dealing with namespaces - how it handles exceptions locally unless you specify otherwise. Of course, these "features" can be put to good use in the right situations, but they can be confusing for a developer without a keen eye.

As SeanJA points out in a new post to his blog, there's two functions that were included in the PHP 5.3 version of the DateTime object in PHp that weren't in the PHP 5.2 version - specifically the get/setTimestamp ones.

These are some strange methods to be missing as a lot of people in the PHP world seem to work on Timestamps using these concepts, so you would have thought that php would have included these methods initially. Unfortunately they did not, so here is a fix for that.

He provides two pieces of code, one to replace the setTimestamp function and the other for the getTimestamp to add in this handy functionality as you might need it.

In response to another blogger's review of the php|architect "Guide to Programming with Magento", Michael Kimsal has posted some clarifications.

Starting off with "However, I'm not really the type of person to give accolades unless something is absolutely stellar. As such, this post will primarily be about the shortcomings of the book" I wasn't particularly surprised that there was more of a focus on negatives rather than positives.

Michael mentions three topics - the "first to market" point the reviewer makes about different versions of Magento between the book being authored and the release, some of the missing information the reviewer would've liked to see and the complexity of the example module that the reviewer complains is too hard to follow.

Jonathan Snook has posted about a method he's using to make the creation/use of static pages in a CakePHP application (or website) simpler.

Traditionally in a CakePHP application, to do static pages you have two options: use the built-in Pages controller or set up an empty action in a controller.

Feeling that neither of these two options met how he wanted things to work, Jonathan (and Nate Abele) developed a class that extends the error handler in the CakePHP framework to handle "missing" actions and controllers. This means that, if an unknown controller/action combo is called, this script will check in its correct location (in the structure of the site) and try to find it to render it.

In this post from Padraic Brady, he compares some of the tools that are available to Ruby developers to some of their counterparts (if they exist) in PHP.

Anyways, here's the pitch. I've been using Ruby for a year now and my pet peeves with PHP started getting a bit too much to comfortably endure. [...] I don't like developing web applications with Ruby, or that thing Rails. Whatever it is. It's a framework, right? So I'm on a splurge of writing PHP tools for the same things in cahoots with folk like Travis Swicegood.

Tools he mentions include Autotest, Mutation testing, Mocha, Rspec, Heckle and some of their PHP counterparts like parts in PHPUnit and the DomDocument functionality.

Mike Lively is happy about one thing - that late static binding (definition) has been committed and will be included with PHP 5.3. Unfortunately, he has a downside too:

The good news is late static binding has been introduced into head and looks like it will be merged into 5.3 before it is released. The horrible news is I really don't think the patch went as far as it needs to.

He talks about the original intention of the functionality (flexible inheritance for static methods/properties/constants) and how it was implemented, but with one small issue - that "static will ALWAYS return the 'resolved' name of the class used to call the current function". He illustrates with a code example showing an extended class returning a static property.

He also mentions two suggestions to help fix this issue:

• setting the behavior of parent:: such that it forwards the calling class through the next function call.
• introducing another scope [...] using a new keyword so parent:: could remain the same

Gregory Szorc has posted his look at the "many untapped features" that PHP has to offer that the masses can tend to overlook when developing applications, specifically when dealing with object versus procedural programming.

The more interesting topic is why these applications have not made the jump to utilize PHP 5's features. Others have speculated, and I tend to agree, that application developers are worried that PHP 5 adoption is too low and requiring its use will turn away users. Now, considering the improvements of the PHP 5 engine, both from a performance and security standpoint, there is no reason in my mind why a sane system administrator wouldn't be running PHP 5.2.1 (most recent at the time of this entry).

He looks at applications like WordPress, Drupal and Gallery and note how they haven't made the move to true PHP5-style code. Adoption has a lot to do with this, but he brings up the point of the article - that developers are "ignorant" to what they're missing.