In his latest post Nikita Popov highlights one of the topics from this post, primitive types as objects, and some alternative options.

A few days ago Anthony Ferrara wrote down some thoughts on the future of PHP. I concur with most of his opinions, but not all of them. In this post I’ll focus on one particular aspect: Turning primitive types like strings or arrays into “pseudo-objects” by allowing to perform method calls on them. [...] Note that this isn’t far off dreaming, but something that already exists right now. The scalar objects PHP extension allows you to define methods for the primitive PHP types. The introduction of method-call support for primitive types comes with a number of advantages.

Among the advantages he lists:

• The opportunity for a cleaner API (instead of the current, sometimes oddly named functions)
• Improved readability
• Polymorphism through a "cleaning up" of shared methods
• Loose Typing

He also looks at possible ways that other primitive types could be handled (like "null" or "float") and some of the problems that could come up when passing objects around. Since the values could be an object or scalar, how would you know the difference. He finishes off the post with a look at the current state of things, including that there's not much resistance just that there hasn't been a good API defined to make it work.

In Volker Dusch's latest post he makes a suggestion to the PHP community as a whole - stop pretending PHP is a good language and admit its flaws where it has them.

I'm currently observing two kinds of discussions around the core PHP language. A couple of folks say "Sure the language sucks but look at all the amazing stuff we build with it!" and the other camp goes "Look at all the amazing stuff we build - The language can't be that bad!". The main point here is that the PHP applications that have been created over the years are incredible. [...] The astonishing dominance of PHP in the Web doesn't come from the fact that it is a good language, it comes from the fact that it allowed people to create and maintain things that are really useful.

He gets into some of the "it's not okay when..." kinds of things that PHP allows, things like:

• Presenting the user with the "White Page of Death" when the script dies because of an error
• Output of basic operations could depend on the environment it's run in
• Problems with type hinting
• Not being able to talk to two backend sources at once

He also suggests a few things that you can do to help the situation including not sending angry emails to the internals mailing list and contribute back with something useful instead (like RFCs).

The claim that "PHP is this awesome enabling language that let's you focus on doing awesome things" doesn't hold up when all of the gains are wasting dealing with the obtuse errors.

Lorna Mitchell has posted a quick checklist of things you can ask about your API to see if it's RESTful or not (five of them):

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. [...] A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

• It has a single endpoint
• All requests are POSTs
• Response metadata is in the body, not header
• There are verbs in the URL
• The URL includes method names

She suggests, though, that "being RESTful" isn't a requirement for "being useful" when it comes to APIs.

In this recent post Nikita Popov looks at some of the usefulness of PHP and some responses to this post from Jeff Atwood about the language.

People come to PHP because they have some problem and they need to solve it. This is what PHP really shines at. You can simply take your static HTML website, add a simple <?php include 'counter.php'; ?> in there, and … be done! From there you start writing simple scripts, learn how to process forms, how to talk to the database, etc. After some time you start using object oriented programming and maybe make use of some framework.

He supports Jeff's thoughts on the usefulness of the language, but points out one part of the post that clearly shows an incorrect view of PHP's current state. It points out how "so little has changed in PHP" and Nikita refutes it with some of the most recent updates including advanced OOP support, namespacing and lambda support.

In a new post to his blog Jigal Sanders shares some of his experience in working with Doctrine 2.1 in a Zend Framework-based (1.11.9) application for his database interface needs.

I hadn’t been using Doctrine for a while and decided to pick it up two weeks ago, as we wanted to see if we can implement it for our CMS at our office. So I setup a clean installation of the zend framework (1.11.9) and tried tried to implement Doctrine. The main goal was to see if we can reverse engineer existing databases and then start doing some queries.

There were three things he found in the process that caused a few issues:

• A confusing set of terms and features that weren't explained well enough to know their use
• Getting things like autoloaders working with the Zend Framework to make things work well together
• A potential bug with the "name" property on an object and some automatic namespacing Doctrine tries to do

There are already a lot of resources available on the Internet. I have looked at various configurations, like for example the 'bisna' project from Guilhere Blanco. But I keep saying that it’s really difficult and has a steep learning curve. Doctrine 1.2 was really simple. Doctrine 2.x is a lot more difficult to get into.

The Ibuildings techPortal has posted the latest episode in their DPC09 session podcast series - a talk from Paul Reinheimer about easy and hard problems.

Consider "Easy" problems in web applications, like login forms. On the surface, terribly simple, slap some escaping functions on a query and you’re done! Well, not quite, what about brute force login attempts? Locking accounts? Captachas! This talk will examine a few of those easy problems, how hard they really are, and present specific solutions and methodologies.

You can either listen to this latest episode in-page or download it directly.

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.

From a pointer from the Zend Developer Zone, there's a link to this case study of the creation of a search engine surrounding the Zend_Search component of the Zend Framework.

We have implemented Zend_Search into our content management system "Click and Change" and we would like to share our experiences with the developers' community. For this purpose, we decided to publish the complete source code and it's documentation.

They give a great overview of the application, from some of the interesting things they came across during development to some of the feedback/questions they've already recieved about the project. They have the source code for each of the files in the search engine, including small changes made after the fact. You can also download the entire project in one zipped up file.

From a pointer from the Zend Developer Zone, there's a link to this case study of the creation of a search engine surrounding the Zend_Search component of the Zend Framework.

We have implemented Zend_Search into our content management system "Click and Change" and we would like to share our experiences with the developers' community. For this purpose, we decided to publish the complete source code and it's documentation.

They give a great overview of the application, from some of the interesting things they came across during development to some of the feedback/questions they've already recieved about the project. They have the source code for each of the files in the search engine, including small changes made after the fact. You can also download the entire project in one zipped up file.