Freek Lijten has posted another "Currently on PHP's internals..." post to his blog today (here's the previous one) with a look at the discussions around the idea of having "property accessors" in PHP - a standardized way of defining getters/setters in objects.

Today I will be discussing a feature that at this moment is called "Property Accessor". It is a method of defining getters and setters. Originally an RFC was defined as early as september 2009, but recently new discussion took place and an actual patch was created. There is no certainty this feature will ever make a PHP version but discussion seems to target implementation details and not the feature itself, so things are looking bright for this feature.

There's two RFCs posted about the topic - the original proposal (from Dennis Robinson) and a patch for implementing them (from Clint Priest). The proposal replaces the common magic getters/setters (__get & __set) with the optional "get" and "set" keywords inside of custom-defined properties.

If you missed out on the Future of PEAR/Pyrus webcast event put on by Engine Yard, you're in luck - they've posted a recording of the event.

In this panel discussion, we tackle topics including the direction PEAR and Pyrus will be going in the next few years, obstacles that may be on the horizon, and more.

PEAR is the package library of standardized packages for a variety of common development tasks. Pyrus is a new package manager to make installing and maintaining PEAR packages simpler. Engine Yard's next webcast will cover the Lithium framework with core contributors Nate Abele, Garrett Woodworth, and John Anderson on December 1st.

Padraic Brady has posted his own response to some of the recent talk about making standard interfaces in PHP applications. His perspective focuses on interfaces and coupling as related to the Zend Framework.

Every PHP framework has it's own unique set of interfaces for common operations such as logging, caching, http clients, filtering, validation, etc. This creates a situation where a framework tends to be loosely coupled but only within the scope of its own interfaces. [...] Loose coupling is therefore a bad joke. It is a narrowly defined concept usually described within the scope of one particular application. We never really apply the concept across multiple applications written with different frameworks because, at that point, the disparate interfaces of both frameworks would immediately make loose coupling unobtainable.

He goes on to talk about a simple example, ZendFeedReader, and how it's very difficult to swap something as simple as the HTTP client out for one from another framework. He mentions the common scapegoat for over-interfacing - Java - and how PHP's is a bit more "practical and flexible" in that department (a good and bad thing).

So yes, common interfaces would benefit PHP and would make framework libraries more interoperable and thus usable within competing frameworks. Hey, if you can't beat them at least make sure you can inject your classes into them. Hmm, still sounds dirty.

Lukas Smith has posted a look at some of the things that have been included in the latest revisions of the Symfony2 framework.

Since about 4 weeks I have really started using Symfony2, in development for a work project no less. Kinda crazy seeing its still in pre-alpha phase, but I think its a great platform today and I know its going to be the best soon aka once we have a stable release. But in these 4 weeks quite a few things have popped up that I like to see addressed. Most things aren't really about writing code, but figuring out how things should be. The kind of stuff that is hard to fix on your own.

He mentions six different things (one or two with code examples) that are new to the framework or are being newly discussed:

• Making 3rd party controllers truly reusable
• Flash message handling
• Easy DIC customization of 3rd party Bundles
• Issues with setting GET parameters in functional tests as well as forward() calls
• Form validation issues
• Aligning the handling for Bundle configuration

On the TechChorus blog today Sudheer has posted his answer to a question posed to him on LinkedIn - "What is your definition of a 'true PHP developer'?" His short answer? The question is wrong. Here's the long answer:

A true PHP developer is a programmer who knows PHP. A false PHP developer is someone who doesn't know PHP. That's the closest correct answer I can think of. I think, Jamie wants to ask, "what's your definition of a good PHP developer?". There is no correct answer to the question. All, you can do is highlight some of the good things a PHP developer does. Let's seize this opportunity to talk about the traits of a good PHP developer. Most of the things that apply for a discussion about good PHP programmer also applies to a good web developer and good programmer in general.

He lists some of the criteria he thinks personifies good PHP developers including:

• A good PHP programmer writes PHP code everyday
• A good PHP programmer always keeps security in mind
• A good PHP programmer knows a bit of JavaScript
• A good PHP programmer keeps an eye open for trending technologies
• A good PHP programmer knows at least one popular framework very well
• A good PHP programmer embraces industry best practices
• A good PHP programmer is comfortable working with version control systems
• A good PHP programmer keeps a tab on PEAR and PECL
• A good PHP programmer writes articles

There's quite a few more than just those listed, so be sure to check out the full list for more good suggestions.

On InfoQ.com there's a recent discussion with three members in a virtual panel discussing a common question among businesses all over the world considering PHP - is it ready for the Enterprise?

Although PHP boasts of being the most widely used environment for web application development, it has been traditionally considered as not suitable for the enterprise. InfoQ has conducted a virtual panel regarding the evolution of the language/platform and its suitability in enterprise environments.

The three members of the panel (Zeev Suraski, Rob Nicholson and Derick Rethans) are asked about PHP's interoperability with other platforms, the trend of scripts moving into a JVM, the transitions from the major versions of the language (ex. PHP4 to PHP5), the role more advanced features might play in PHP and if PHP might be considering a move into more functional programming.

PHPFreaks.com has posted this new information about running PHP on a Windows 2008 Server instance and how you can give it a try for thirty days.

Microsoft has been recently engaging in a number of open source projects. They have been working on enhancing performance, security and stability of PHP applications on Windows Server platforms. [...] In cooperation with Microsoft, [we] invite you to trial a Windows based web stack consisting of IIS 7, PHP 5 and SQL Server. Via the PHP on WS 2008 website you will be able to request a 30-day trial with a Microsoft hosting partner

By signing up, you can request a trial of the IIS 7 software. They also provide a Q&A discussion board for those participating in the program that might need any help.

Paul Gregg has a quick post informing PHPers that use of some of the resources and groups the LinkedIn service has to offer.

Since LinkedIn opened up its Groups system, there has been a huge growth in the number of groups related to PHP. Some with charters, some without; some with a specific community background and others with a specific regional focus. I am posting this to bring attention to some of them.

Among the groups on his list are ones like LinkedPHPers, PHP Technology Specialists and a PEAR group. There's a lot of recruiters that come through trolling for jobs on some while others ban those posts all together - it just depends on the group.

This post on the JankoAtWarpSpeed blog started off a discussion between PHP and ASP.NET developers as to why one would go for the first over the second.

The first thing that came up to my mind was that PHP is quite simple language comparing to ASP.NET (.NET actually) which is a complete framework that offers a wide range of possibilities (yeah I made a comparison). Maybe PHP has a simple learning curve comparing to ASP.NET, but why would web designers care for data access layer or OOP anyway? But on the other hand, it doesn't mean that web designers should limit their selves just to PHP. Why not be familiar with other technologies as well?

The post has lots of comments from both sides of the fence, each espousing their language of choice. Reasoning ranges from "because ASP.NET is a Microsoft product" to the price of ASP.NET hosters to PHP's open source-ness and the much different learning curves.

Jamie Hemmett has a few suggestions for local user groups out there on what to do and not to do to help make their group successful. Some of it was gathered from personal experience, other tips from the recent user group panel discussion from this year's ZendCon.

I just listened to the PHP User group Panel discussion from the Unconference session at ZendCon. While I listened I took some notes to try and help our Irish PHP Users Group be awesome like some of the other groups out there. I reckon the podcast and great tips it contains will help other User Groups out there too (not just PHP).

Some of the observations/comments she mentions include:

• Freelancing PHP developers may not feel like attending a group with "the competition"
• Several factors dissuade developers from attending (distance, confusing schedules, timing)
• Some ideas that groups out there could use to attract and keep more members
• Why the groups can make you a better developer
• and some sponsorship/promotion ideas to help grow and better the group

This is a great post packed with some good suggestions and observations. If you're involved at all in your local group (or would like to be) be sure to read it.