Robert Basic has a new post to his site where he shows how to use the Mockery unit testing too to return different values for different arguments. Fortunately there's something already built into the tool to help handle this.

Sometimes when working with Mockery mock objects, we want to tell a mocked method to return different values for different arguments. It is a rare occasion when I need this feature, but every time I need it, I’m happy it’s there.

The feature that allows us to return different values based on arguments is the andReturnUsing Mockery method, which takes a closure as an argument.

He includes examples of the use of this andReturnUsing method in mocks and showing that there's more than one way to accomplish the same kind of goal. While this is a useful method to use when needed he points out that refactoring the code under test is probably a better way to go instead.

Rob Allen has posted a quick tip for the Slim framework users out there showing how to use default route arguments in your application.

A friend of mine recently asked how to do default route arguments and route specific configuration in Slim, so I thought I'd write up how to do it.

He illustrates with a simple "Hello world" route that responds using the "name" value from the URL path. He then shows how to modify this example and define a default using the "setArgument" method on the route itself (for both single and multiple values). He ends with an example of how it can be applied for other values needed in the route as well, like a "role" for access control handling.

On the Amazium blog Jeroen Keppens has a recent post looking at some of tools available to you when needing to filter input and escape output in your applications. This post specifically covers filtering on command line applications.

When you need data input in a web context, you send a GET/POST request to your script. On the command line, things work differently. In this blog post, we will talk obout input and output in php-cli.

The post is broken up into a few different sections:

• Handling arguments
• File descriptors
• Interactive input
• Resources mentioned in the post

Tools mentioned include everything from getopt and PEAR's' Console_Getopt out to using file descriptors and working with readline.

Christan Stocker has posted a finding of the day that he ran across and wanted to share to help out other developers out there:

For okapi we needed to have a function which loads any class with any number of arguments. This is not so easy in PHP as it looks like [...] Since 5.1.3 you can use the reflection extension to do this much nicer.

The difference comes in at about half the time for both side of the examples - with the switch and via reflection.

On PHPHacks.com, there's a new tutorial that covers a a use for PHP that's not utilized nearly enough - working with it on the command line, shell scripting.

As most of us already know, PHP is the best language for developing dynamic web pages available today. Not many people are aware that it can be used as a shell scripting language as well. While PHP as a shell script isn't as robust as Bash or Perl it does have definite advantages, especially if you're like me and are more proficient in PHP than you are in Perl.

The requirements for using PHP as a shell language is that you must compile PHP as a CGI binary instead of as an Apache module. There are certain security issues related to this so please refer to the PHP Manual when doing so.

The author shows a simple example first, just outputting information. He also demonstrates how to grab the input parameters and how to read in from the command line interactively (both single lines and multiple).

On PHPHacks.com, there's a new tutorial that covers a a use for PHP that's not utilized nearly enough - working with it on the command line, shell scripting.

As most of us already know, PHP is the best language for developing dynamic web pages available today. Not many people are aware that it can be used as a shell scripting language as well. While PHP as a shell script isn't as robust as Bash or Perl it does have definite advantages, especially if you're like me and are more proficient in PHP than you are in Perl.

The requirements for using PHP as a shell language is that you must compile PHP as a CGI binary instead of as an Apache module. There are certain security issues related to this so please refer to the PHP Manual when doing so.

The author shows a simple example first, just outputting information. He also demonstrates how to grab the input parameters and how to read in from the command line interactively (both single lines and multiple).

As long as people "choose sides" when it comes to programming languages, there will always be articles like this to compare them. This time, it's a look at PHP versus another much-loved language, Perl.

The article takes a look at several different topics under this one umbrella, including:

• Arguments and return values are extremely inconsistent
• PHP has inconsistent function naming
• PHP has no lexical scope
• PHP has too many functions in the core

Obviously, they all seem to take a negative slant on PHP, but they do provide some content under each of the headings to back up their claims. They break out the contents of each of these examples to make comparison of Perl's and PHP's similar functionality easier. At the end, they also provide links to other resources and other posters illustrating some of the points they've shown.

As long as people "choose sides" when it comes to programming languages, there will always be articles like this to compare them. This time, it's a look at PHP versus another much-loved language, Perl.

The article takes a look at several different topics under this one umbrella, including:

• Arguments and return values are extremely inconsistent
• PHP has inconsistent function naming
• PHP has no lexical scope
• PHP has too many functions in the core

Obviously, they all seem to take a negative slant on PHP, but they do provide some content under each of the headings to back up their claims. They break out the contents of each of these examples to make comparison of Perl's and PHP's similar functionality easier. At the end, they also provide links to other resources and other posters illustrating some of the points they've shown.

On Codewalkers.com today, there's a note about an interesting bit of discussion going on over on the PHP mailing lists dealing with "named arguments".

There is an interesting discussion going on in the internals list on whether or not to have named arguements in php6. The start of the discussion is here with a break off thread here.

Named arguments would allow you do to something like this:

testFunc(name:"test",vals:"stuff")

Naming the items in the code and allowing them to be accessed via one variable internal to the function. There are some pretty good arguments on both sides of things, but it still doesn't seem like it's going to be taken much further than this...

On Codewalkers.com today, there's a note about an interesting bit of discussion going on over on the PHP mailing lists dealing with "named arguments".

There is an interesting discussion going on in the internals list on whether or not to have named arguements in php6. The start of the discussion is here with a break off thread here.

Named arguments would allow you do to something like this:

testFunc(name:"test",vals:"stuff")

Naming the items in the code and allowing them to be accessed via one variable internal to the function. There are some pretty good arguments on both sides of things, but it still doesn't seem like it's going to be taken much further than this...