The SitePoint PHP blog has posted another tutorial from author Christopher Pitt sharing another one of his "interesting things" you can do with PHP. In this latest article Christopher returns to the idea of "macros" to help with some pre-processing in PHP applications and, ultimately, creating a new language feature without some of the usual overhead.

Let’s have a bit of fun. A while ago, I experimented with PHP macros, adding Python range syntax. Then, the talented SaraMG mentioned an RFC, and LordKabelo suggested instead adding C#-style getters and setters to PHP.

Aware of how painfully slow it can be for an outsider to suggest and implement a new language feature, I took to my editor…

He starts with a brief refresher on macros to do some pre-processing on PHP scripts and allow you to make custom language features that then get interpreted into valid PHP (often with some interesting eval tricks involved). He starts by building a "base" to add in the C# style getters and setters in a special format inside of a class. He includes the macro definitions to set this up and the result once it is passed through the "yay" precompiler. To get around having to run that precompiler every time manually, he creates a custom autoloader to do the job dynamically. He then takes this logic and packages it up so it can be easily installed as a Composer dependency. With this structure in place, he moves on to the creation of a new language feature - the actual functionality for the getter/setters. He ends the post with a screen capture showing the language feature in use and some of the interesting things you can do with it.

Accessing private class properties via getters and setters is a pretty standard way to write your applications. Unfortunately it can be time consuming to write them for every property your class may have. On 7PHP.com Khayrattee Wasseem has a few ideas (including using PHP's own Reflection functionality) to dynamically create them.

When coding a project, at times (or most of it?) some classes might have more than 3 fields (for whatever reason it suits you). So instead of each time writing and repeating setters and getters (accessor methods), I would like to have a piece of reusable code for all my classes without me ever writing a single line of code for accessors. (‘ever’ as in ‘very very rarely’). Now, we also have to take into consideration that some fields might be only get-able or only set-able – (our re-usable piece of code should cater for this)

He shows two different methods to accomplish this kind of dynamic access, one using traits and the other using normal class inheritance. HE includes the code illustration each solution and talks a bit at the end of each section of why that method might be better than the other.

Russell Walker has a recent post to his site looking at different ways to work with class properties including using them as public properties or using getters and setters.

Opinion seems to be divided on whether it is good practice to use public properties in PHP classes, or whether to use getter and setter methods instead (and keep the properties private or protected). A sort of hybrid third option is to use the magic methods __get() and __set(). As always, there are advantages and disadvantages to each approach, so let's take a look at them.

He breaks the rest of the post up into three sections, each with a bit of a code example and the common advantages/disadvantages. It's a good overview of the three types and, in the end, it's mostly about what works for your applications. What's his favorite?

My choice then is to use public properties most of the time, but getters and setters for critical settings that I feel need stricter control, would benefit from lazy loading, or that I want to expose in an interface.

Josh Adell has a new post to his blog talking about a debate between developers over which is the better method - using public properties or getters and setters to work with values on your objects.

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.

In a quick new post to his blog, Rob Allen has shared a snippet for the Sublime Text 2 editor to make creating getters and setters for your class simpler (dynamically too).

As with a lot of editors, Sublime Text supports snippets which are essentially text expansions of a short phrase into more text. I needed to create a few getXxx() and setXxx() methods for some properties of a class and decided that the easiest way to do this would be with a snippet.

Included in the post is the code you'll need to put into the snippet - a simple find (regular expression based) looks at the currently selected variable and expands out the getter and setter for it. For more information on the Sublime Text 2 editor, see the product's website.

Bence Eros has put together a new post to his blog looking at some of the results he's found from performance testing the use of getters and setters in PHP.

The usage of getter and setter methods instead of public attributes became very popular in the PHP community, and it's going to become the standard coding convention of so many PHP libraries and frameworks. On the other hand many developers - including me too - strongly unrecommend such convention, because of its performance overhead. I wanted to make some performance comparison for years, and today I had time to do that. In this post I would like to show what I found.

He starts with a question every developer asks as their working in their application - why and when should they use getters and setters for their classes. He talks about using them as primary functionality or as fallbacks only when needed. He includes the simple benchmarking script he used to compare accessing/setting public attributes directly and using a getter/setter to do the same. The results aren't very surprising if you think about the "magic" that has to happen for getters and setters to work. See the rest of the post for those numbers.

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.

On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

• passing values in through the constructor
• using the "Information Architect" pattern to have the most responsible method handle the value setting
• the "Double Dispatch" method that uses dependency injection
• using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.

In a new post Berry Langerak wonders if the getters and setters commonly used in PHP applications are a necessary evil and if they should be used at all.

Although I do still feel like getters and setters are to be avoided most of the time, it’s hard to tell where to use them and where you shouldn’t. [...] While writing the code for [PFZ.nl], I started to notice that each and every class in the system had accessors for most, if not all, protected fields. I’ve started a discussion with my fellow developers, and this is what I’ve argued.

He mentions a few things including an article he'd written previously on the topic, some of the points behind OOP programming, encapsulation and accessors and collaborators. He also includes several code examples showing what he considers right and wrong ways to do thing (warning, opinions ahead).

All in all, I don’t think accessors are evil per se, but you should only ever use the accessors in cross-layer situations. Don’t use accessors to build functionality, but only because you need the value to display and/or save.

In this recent post to his blog Michael Kimsal asked about the usefulness of the __get and __set magic methods and the sort of code he usually sees along with it.

For a long time I’ve held that __get and __set in PHP were not all that hot - mostly because it’s solely error handling. There’s no way to deal invoke __get or __set behaviour for properties that are defined on a class. [...] For those who insist on using __get/__set, I *typically* see this [messyy] sort of style code. The effect is to cram a bunch of unrelated code in to the __get/__set overloading methods.

He suggests an alternative to the "cram it all in __get" approach - callbacks to other methods in the class to handle the different variable possibilities. In the comments there's other suggestions on how to get the same job done differently - mapping property values with __call, valid uses for getters/setters and a pointer to an internals discussion RFC about this same thing.