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.

In a new blog post Matthew Weier O'Phinney has taken a look at proxy objects (the Proxy design pattern) and how it differs from some of the other popular patterns.

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.

Shawn Stratton has a new post to his blog talking about a topic he calls "flame bait" - the use of accessors in PHP applications (getters and setters) to access class 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.

Cal Evans has posted the eighth tip in his six-tip series (but who's counting) about how a client can coordinate better with a developer and make a better relationship for the project. In this new tip, he suggests that the client "own it".

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).

Tom Rawcliffe has posted the latest installment of his look at design patterns in PHP. This time his focus is on the Decorator pattern.

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.

Wojciech Sznapka has a new post to his blog showing an interesting OOP programming strick related to accessing private properties in one object from another if they're derived from the same class.

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.

On his blog today Vance Lucas has posted a method you can use to only get the properties of your class that are in the "public" scope.

PHP provides two built-in functions to retrieve properties of a given class '" get_object_vars and get_class_vars. Both these functions behave the same exact way, one taking an object as a variable and the other taking a string class name. The tricky thing about the two functions is that they behave differently depending on the call scope, returning all of the class variables available within the called scope.

As a bit of a hack (in lower than PHP 5.3) he shows how to use the create_function function to create a small statement in a different scope that returns the only the variables seen from the "outside" - just the public ones. PHP 5.3 users can do it much more cleanly with closures. Code examples for both are included.

Fabien Potencier has posted a look at dependency injections - what they are and how they can effect your code (usually for the good).

Dependency Injection is probably one of the most dead simple design pattern I know. And odds are you have probably already used Dependency Injection. But it is also one of the most difficult one to explain well. I think it is partly due to the nonsense examples used in most introductions to Dependency Injection. I have tried to come up with examples that fits the PHP world better. As PHP is a language mainly used for web development, let's take a simple Web example.

His example uses a session variable, setting it to a language preference and wrapping a class around it to handle the getting and setting. The dependency injection comes in when he adds a SessionStorage class into the mix, a tool that could change the place and method where that session information is held. He suggests that the best place to set these kinds of dependencies is usually the constructor but it can be done as a setter or property injection too. It just depends on the need for the script at the time.

For those Komodo users that are working with CakePHP and have thought "there has to be a better way", Matt Curry has created a screencast showing a few helpful hints on developing in popular IDE.

I suck at screencasts; I know this. If I keep doing them, I'm bound to get better, right? Is it possible to get worse at something the more you do it? Anyway, I made a quick screencast showing off some CakePHP features with Komodo IDE. Leave a comment with your favorite CakePHP related IDE trick.

He talks about the "automatic" auto-completion the IDE can do once its scanned the CakePHP source, how Komodo knows about properties in the classes as well as helpers and how to set up the Bake and Cake commands as shortcuts for quick access.

In the first of his "I will insult your code" series, Nate Abele looks at this submitted code and points out that maybe blocks of switch/case statements aren't such a good idea after all.

The entire submission is actually two files, which together comprise a console script for interacting with a web service (the names of the entrants have been withheld to protect the identities of the guilty). Rather than examine the full entry, we're going to take a look at one part which I find comes up fairly often: switch block overkill.

The example he's talking about has a switch statement with eight different cases under it, most of them just setting two properties on the current class. Its used ot map command line parameters to their correct properties. Nate suggests a bit different method - still using switch/case but pulling the properties to be assigned from an array of options rather than hard-coding them into the evaluation.