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

PHP Town Hall Podcast:
Episode 40: Return of the Ferrara
Apr 23, 2015 @ 09:02:26

The PHP Town Hall podcast has posted a new episode today with the Return of the Ferrara. Hosts Ben Edmunds and Phil Sturgeon are joined once again by guest Anthony Ferrara to talk about, among other things, scalar type hints.

Regular guest Anthony Ferrara joins us “in the studio” to talk about the new version of his scalar type hints, which since recording - a f**king month ago - has been accepted for PHP 7. We thought it would be good to have a bit of a chat about the feature, the nonsense that surrounded it and a bunch of other random internals and PHP 7 related blathering.

You can catch this latest episode in a few different ways, either through the in-page audio player, by downloading the mp3 or through the video recording of the live session. If you enjoy the show, be sure to subscribe to their feed too.

tagged: phptownhall podcast ep40 return anthonyferrara scalartypehints php7 interview

Link: http://phptownhall.com/blog/2015/03/20/episode-40-ferrara-scalar-type-hints/

Mathias Noback:
Some questions about the command bus
Jan 12, 2015 @ 09:46:46

Mathias Noback has continued his series looking at the use of command busses in PHP applications. In this third part of his series, he answers some questions that have been asked by his own readers.

So far we've had three posts in this series about commands, events and their corresponding buses and handlers: a wave of command buses, responsibilities of the command bus, from commands to events. Now I'd like to take the time to answer some of the very interesting questions that by readers.

He answers questions about:

  • The difference between commands and events
  • Disadvantages of using a command bus
  • The command as constructor argument
  • How to return a value from the command bus
  • Could commands handle themselves?

Each question comes with a portion of the question from the original author, an explanation and some code where needed to illustrate his point.

tagged: commandbus question answer reader events disadvantages return handling

Link: http://php-and-symfony.matthiasnoback.nl/2015/01/some-questions-about-the-command-bus/

Matthew Weier O'Phinney:
Deployment with Zend Server (Part 5 of 8)
Sep 10, 2014 @ 13:40:49

Matthew Weier O'Phinney has posted the latest in his "deployment with Zend Server" tips today, part five of eight. In this latest post he talks about setting the status of a job.

This is the fifth in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed how to secure your Job Queue job scripts. Today, I'm sharing some best practices around writing job scripts, particularly around how to indicate execution status.

When he talks about the "status" of a job he's referencing the return code that's provided back to the executing script sharing the pass/fail status of its execution. He shows how to use the ZendJobQueue object and the setCurrentJobStatus to return a constant, either "FAILED" or "OK". He shows how to use it in an isolated example, outputting the results back as a plain text message that can be found in the "Output" tab of the job.

tagged: zendserver deployment tips series part5 return status failed ok

Link: https://mwop.net/blog/2014-09-09-zend-server-deployment-part-5.html

Federico Cargnelutti:
TDD: Checking the return value of a Stub
Apr 16, 2014 @ 10:25:15

Federico Cargnelutti has a helpful post to his site today for the unit testing/TDD crowd about checking the retuned value from a stub of an object in your tests. He's using the built-in mocking framework here, not something like Mockery.

State verification is used to ensure that after a method is run, the returned value of the SUT is as expected. Of course, you may need to use Stubs on a test double or a real object to tell the object to return a value in response to a given message. [...] In PHP, for example, you dynamically type the return value within the body of the method. This means that PHP mocking libraries cannot check the type of the return value and provide guarantees about what is being verified. This leads to the awkward situation where a refactoring may change the SUT behaviour and leave a stub broken but with passing tests.

He gives an example of a few classes - a Presenter and Collaborator - and a test that mocks out the Collaborator instance, calling a "getStories" method on it. He shows a situation where all tests pass in the initial version, but after some changes to the return type, a test that should fail doesn't. His solution for the issue revolves around DocBlock annotations and the Return Value instead of the built-in mock object return method.

tagged: tdd unittest return value stub passing test returnvalue mock

Link: http://blog.fedecarg.com/2014/04/15/checking-the-return-value-of-a-stub/

Derick Rethans:
DateTimeImmutable
Feb 26, 2014 @ 10:26:45

In his latest post Derick Rethans (knower of all things date and time) talks about the DateTimeImmutable functionality. It has been added into the PHP 5.5 releases and provides the same DateTime functionality but removes the ability for modification (mutability).

The first time that my improved DateTime support made its way into PHP was officially in PHP 5.1, although the more advanced features such as the DateTime class only made it appearance in PHP 5.2. Since its introduction the DateTime class implementation suffered from one design mistake - arguably not something that even an RFC would have highlighted. [...] This mutability property that all modifying methods of the DateTime class have is highly annoying, and something that I would now rather remove. But of course we cannot as that would break backwards compatibility. So in PHP 5.5, after a few stumbles, I finally managed to rectify this.

He includes some code examples showing the current DateTime object's mutability (via the "modify" function) and the new immutable handling. This new handling doesn't update the current object but instead returns the modified object, leaving the initial one intact. You can find out more about this new object in the PHP manual.

tagged: datetime datetimeimmutable mutability return object php55

Link: http://derickrethans.nl/immutable-datetime.html

Chris Hartjes:
Data Providers and Arrays
Oct 28, 2013 @ 11:49:36

Chris Hartjes, testing guru, has a post talking about using arrays in data providers for your unit tests. More specifically about some odd behavior one developer was seeing in their tests.

I was asked a question on Twitter by Tex Morgan about a problem he was having with PHPUnit data providers. He was trying to pass in some data and kept wondering why PHPUnit was serializing the data instead of doing what he was expecting.

The issue (example code included) was in how the data providers are expecting the data to be returned. His test was expecting an array but the data provider was returning things incorrectly. As Chris points out, the provider should return an array of arrays. The fix is easy, but could be confusing to someone not used to this slightly unusual return format.

tagged: data provider unittest array return value example

Link: http://www.littlehart.net/atthekeyboard/2013/10/26/data-providers-and-arrays/

Rob Allen:
Returning JSON errors in a ZF2 application
Sep 09, 2013 @ 10:49:30

Rob Allen has a quick post to his site for the Zend Framework 2 users out there showing how to return JSON errors from your requests.

If you have a standard ZF2 application and accept application/json requests in addition to application/html, then you have probably noticed that when an error happens, HTML is created, even though the client has requested JSON. One way to fix this is to create a listener on MVC's render event to detect that an error has occurred and substitute a JsonModel in place of the ViewModel. The easiest way to do this in your ApplicationModule.

He includes some example code showing how to attach a listener for rendering ("onRenderError") and the code that defines the renderer itself. It goes through a series of checks on the request and then gets the error information from the Response. Some common errors are caught and replaced with a default message, otherwise its just directly sent to render. He then attaches the whole thing in the bootstrap and shows a simple way to test the output with a cURL call.

tagged: return json zendframework2 application tutorial render

Link: http://akrabat.com/zend-framework-2/returning-json-errors-in-a-zf2-application/

Larry Garfield:
On empty return values
Mar 29, 2013 @ 09:15:59

Larry Garfield has posted some of his thoughts on return values and reminds you about consistent return types, regardless of the result.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

He proposes a new rule of thumb: "If your function returns a collection, its null value return must also be a collection." A more broad version of this might be: "make your return types consistent." It's all about predictability and the contracts you have between different parts of your code. If a user calls your method expecting to be able to loop over the results, they'll be disappointed with a "false". He talks some about using and throwing exceptions more effectively for error handling and answers several "but wait..." arguments for his return strategy.

tagged: empty return values opinion contract exception expected

Link:

Brandon Savage:
Always Return Something
Mar 12, 2013 @ 10:49:55

In this post to his site Brandon Savage talks about "always returning something" from your methods and functions back to the calling script. He also suggests that null is not an option.

A few weeks ago, there was a discussion on Twitter about whether or not a method should always return a value, or whether or not null was a valid value to return. The answer to this question is a resounding no, a null value should never be returned. [...] For example, you check that a file you opened exists, or that a resource performed correctly before using it. But if you receive a null response, how do you test for this The answer is you can’t

He notes that a "null" response is not only difficult to test but can lead to ambiguous handling as you're not sure where the error might be. He also includes a snippet of code showing how a null response could break a fluent interface if an instance of "$this" is not returned.

tagged: return valid null method function value

Link:

Michael Nitschinger:
A Journey on Avoiding Nulls in PHP
Feb 20, 2013 @ 12:17:39

Michael Nitschinger has written up a post looking at avoiding nulls in your applications in favor of a better kind of value handling - the introduction of "Optional" handling.

While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".

tagged: avoid null return value optional absent present evaluation tutorial

Link: