PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

PHP 5.4 introduced several performance optimizations. One of them was not discussed much in the PHP community but it may affect the performance of your code depending on the way you write it.

He gets into some of the details surrounding the variable access optimization, pointing out how to get the most out of this improvement. He also does a bit of speculation about future versions of the language, including the possible introduction of "Just In Time" compilers.

While PHPUnit is awesome out of the box, it still lacks some tools that are required to do things like test protected class methods or assign values to protected class attributes. Lucky for me we have an awesome testing engineer at Kaplan named Will Parker who has shown me some ways that they have extended PHPUnit itself to make testing certain things easier.

Chris talks about things like testing protected methods (easy thanks to a helper) and checking the value of a class property. The key to both of them lies in using PHP's own Reflection functionality to alter properties on the class objects themselves.

I was recently having a debate with a coworker over the utility of writing getter and setter methods for protected properties of classes. On the one hand, having getters and setters seems like additional boilerplate and programming overhead for very little gain. On the other hand, exposing the value properties of a class seems like bad encapsulation and will overall lead to code that is more difficult to maintain. I come down firmly on the get/set method side of the fence.

In his opinion, the getter/setter method provides an explicit interface to the class that describes what it can do and how you can work with it. He gives code examples, comparing the two methods - simple setting of properties on one object and using get*/set* methods on the other. He brings up the point that, if ever in the future you wanted to handle the data for a property differently, say always make it an array or object. He also points out that this still doesn't prevent the setting of new properties directly, so he uses the magic __get and __set to deal with that.

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.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

Objects have prop­er­ties which some­times need spe­cial logic on how they are retrieved and set. There are sev­eral solu­tions to this and every­body has a dif­fer­ent view point about which is cor­rect, none are pretty and all have draw­backs which range from writ­ing extra code, cre­at­ing some­thing that has poor exten­si­bil­ity, or has issues with con­sis­tency. These don't even breach the issues with IDE code com­ple­tion and analy­sis. Lets look at some of these solutions.

The solutions are the direct access to the class properties (which can cause some painful inconsistencies when things get complicated) and the alternative of setting up getters/setters for everything. Shawn's alternative makes use of the __get and __set magic methods to catch the property values being set and handle them correctly, developers being none the wiser.

No, I'm not talking about own it as in Point 7 - "Do your part", I mean make sure that at the end of the project, you own the project, not your developer.

He mentions two of the aspects you, the client, will need to worry about once the last line of bug free code has been committed and delivered. Be sure that you own the domain name for the project and have a clear understanding of any intellectual property concerns that might come up (what codebase is it built on, who owns the code - client or developer, etc).

Continuing my series on PHP design patterns, today it's the turn of the Decorator. In contrast to last week's Strategy Pattern which is used to change the 'œguts'� of a class, the Decorator Pattern is used to extend the behavior of a class with different functionality at run time. This is achieved by implementing a 'œdecorator'� class that implements the same interface as the object that you wish to 'œdecorate'� and wraps it's content.

The Decorator pattern lets you "decorate" your objects with additional features. He illustrates with a sample "Property" class (that implements an interface) that he wants to extend past the normal property handling. He add a "PropertyDecorator" to the mix that lets it use deocrators for uppercasing and padding the string. There's an example script included at the end that shows how to put it all to use.

Last time I wrote about Weirdest PHP construction I've ever seen, now I found another unusual PHP solution. PHP offers 3 visibility modifiers: private, protected and public. Private properties and methods can't be accessed outside the object, as well as from inherited classes. With one exception... They can be accessed by other instances of the same class. You can read more about it in the PHP manual.

In his code example he shows how to create two objects of the Foo class and, using getters and setters change the value of a private property from the first object on the second object.