Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Freek Van der Herten:
Simplifying presenters in Laravel
Sep 20, 2016 @ 09:32:17

Freek Van der Herten has a quick post to his site with a tip about simplifying presenters in your Laravel based application. The "presenters" here are in relation to this package and how it helps with the output of the application.

In the Laravel template that we use to kickstart all our client projects at Spatie, I recently changed the way we handle presenters. Instead of using Jeffrey Way’s popular presenter package we now use simple traits. In this post I want to give some background on that change.

He gives a quick "crash course" on presenters for those not familiar with the concept and how it helps to keep view logic out of places like models and controllers. He briefly describes a presenter class that would return the "first name + last name" combination and what the code could look like. Then it's just a matter of using that trait (the class mentioned just before this) and a new magic property is defined to use in the view.

tagged: laravel presenter view logic property example user name

Link: https://murze.be/2016/09/simplifying-presenters-laravel/

Giorgio Sironi:
Property-based testing primer
Jun 19, 2015 @ 12:15:29

Giorgio Sironi has a new post to his site today talking about a method (and tool) around a different sort of testing practice: property-based testing. The difference is that, instead of hard-coding values and evaluating them post-processing, you're generating random values and ensuring they match against a set of properties, not values.

I'm a great advocate of automated testing and of finding out your code does not work on your machine, 30 seconds after having written it, instead of in production after it has caused a monetary loss and some repair work to be performed. [...] However, classic test suites written with xUnit and BDD styles have some scaling problems they hit when you want to exercise more than some happy paths. [...] Property-based testing is an approach to testing coming from the functional programming world.

He helps to make the point a bit more clear with an example of testing the "sort" function and its results. He talks about how to test it using normal data, empty data, etc. but notes that this kind of testing can become "boring and error-prone". Instead he proposes the property-based testing of the results. He generates random values to feed into the method and checks to ensure the results are sorting by comparing them to each other. He expands this with a bit more complex example, showing how to test some DateTime handling and evaluating the result with logic in a closure. To help make this kind of testing easier, he's created a library (Eris) that extends PHPUnit and provides the methods seen in his examples.

tagged: property testing unittest phpunit extension random datetime sort eris

Link: http://www.giorgiosironi.com/2015/06/property-based-testing-primer.html

Marc Morera:
Behat and Data-test
Apr 27, 2015 @ 09:55:08

In a new post Marc Morera makes a suggestion for a testing practice to add to the use of the popular BDD PHP testing framework Behat - a "data-test" option to help with decoupling the tests from implementation.

Tests should be as robust as possible. I think you will agree with me with that phrase. If your tests are too coupled with your implementation, a simple modification of your code will need the modification of your tests, and that’s so annoying, right? [...] My question is… should the frontend of your website be aware of the how your Behat tests are built? In my opinion, nope. Your tests should live in a simple layout on top of your application, emulating some cases and ensuring that your users will be able to do what they should be able to.

He points out the main problem with the current testing methods, mainly that the real issue is in the hard-wiring of the test functionality to the name/id/type of the interface elements. He also brings up the aspect of translations and ensuring that your tests take into account that the text may not always be in English. He also mentions Symfony forms and how they define their own structure and naming, not necessarily what you manually generate. He instead proposes a "data-test" property that could be added to elements both indicating that they're used by the testing process and can help in locating the elements during the testing process.

tagged: behat bdd datatest property markup testing method opinion

Link: http://mmoreram.com/blog/2015/04/25/behat-and-data-test/

Mathias Verraes:
Objects as Contracts for Behaviour
Sep 29, 2014 @ 11:10:33

Mathias Verraes has a new post to his site today with an interesting idea when it comes to handling the architecture of an application: using objects as the contracts for behavior. He suggests that the objects themselves define how other pieces of code should interact with them, not necessarily external services. He illustrates with an invoice and appointment example.

Of course invoices do not pay themselves, but that’s not what an object model is trying to do. An invoice exposes the behaviour of being able to be paid. That ability is in fact essential to what it means to be an invoice. The behaviour is an inherent property of an invoice. If an invoice doesn’t have the ability of being paid, there’s no point in issuing invoices at all. In other words, the contract of an invoice object declares that its interface includes payment as a feature. Its promise to the outside world is that it allows an outsider to pay for it. Encapsulation of state and behaviour is the core idea behind objects.

He wonders why, if this is more true to the "object-oriented programming" ideals, the idea of encapsulating procedural code as objects is so widespread. He suggests a lack of education on the subject or maybe even confusion from spoken languages themselves.

tagged: objectoriented programming oop contract expose behavior property

Link: http://verraes.net/2014/09/objects-as-contracts-for-behaviour/

Evert Pot:
Accessing protected properties from objects that share the same ancestry.
Sep 16, 2014 @ 11:19:23

In his latest post Evert Pot shows an interesting side effect of working with two objects from the same class: accessing protected properties from one instance to the other.

I realized something odd about accessing protected properties the other day. It's possible in PHP to access protected properties from other objects, as long as they are from the same class. [...] I always thought that protected strictly allows objects to access things from the current inheritence tree, but didn't realize that this also extends to other instances of the same object.

He includes a bit of sample code showing two object instances each being able to access the protected "val" property from the other. He also shows an example of how it works in two different objects, both that derive from a common ancestor. He shares a few other code examples showing this relationship and points out a few places where it could come in handy.

tagged: protected property object ancestor access

Link: http://evertpot.com/properted-properties-from-shared-ancestry/

Wojciech Sznapka:
Immutable value objects in PHP
May 16, 2014 @ 09:04:27

Wojciech Sznapka has a quick post to his site today looking at a possible implementation of Value Objects (immutable objects) in PHP applications.

Value objects are one of building blocks in Domain Driven Design. They represents a value and does not have an identity. That said, two value objects are equal if their values are equal. Other important feature is that Value Objects are immutable, i.e. they can not be modified after creation. [...] This post isn't about obvious advantages of representing domain logic with support of Value Object. As well, we wouldn't elaborate here about pros and cons of immutable objects. I'd rather would like to show an attempt to change Value Object.

His change method isn't so much a "change" as a "duplicate with new values" process. In his example he creates a EmailValueObject with "host" and "mailbox" properties. This object has a "changemailbox" method that seems to update the "mailbox" property, but in actuality clones the current object with a new "mailbox" value in the constructor.

tagged: value object immutable clone change property

Link: http://blog.sznapka.pl/immutable-value-objects-in-php/

Christian Weiske:
PHP: Cannot access property started with '\o'
Nov 08, 2013 @ 09:59:13

Christian Weiske had an interesting situation pop up in one of his applications around a call to a variable with an interesting name.

Some days ago I saw the following fatal error for the first time in my life:

Fatal error: Cannot access property started with '\o' in file.php

After some debugging, I found out that the source of the error was not some strange BOM or UTF-8 characters in PHP source code files. No, it was a combination of protected class properties, object-to-array casting and automatic template property mappings.

As it turns out, there was a change in how object-to-array casting was done in PHP 5.3 that made this break (related to things appended to private and protected variable names). He includes a bit of sample code to illustrate the problem - a simple class converted from object to array with direct casting. He does point out that it doesn't happen with get_object_vars, though, as that doesn't do the casting, just extraction.

tagged: class property special character private protected casting

Link: http://cweiske.de/tagebuch/php-property-started-nul.htm

Auto Generate Properties Dynamically For Your Classes Using Magic Methods & Reflection
Oct 28, 2013 @ 12:57:14

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.

tagged: reflection getter setter private property tutorial trait inheritance

Link: http://7php.com/magic-dynamic-properties/

Russell Walker:
Public properties, getters and setters, or magic?
Sep 26, 2013 @ 09:58:36

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.
tagged: class property getter setter magic public opinion

Link: http://russellscottwalker.blogspot.co.uk/2013/09/public-properties-getters-and-setters.html

Phil Sturgeon:
PHP 6: Pissing in the Wind
Jan 28, 2013 @ 10:42:16

With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

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.

tagged: opinion php6 unicode property accessors rfc voting