In a post to his site Sebastian de Deyne makes the suggestion that you should normalize your values (input) as soon as possible.

Dynamic languages allow us to pass anything as a parameter without requiring a specific type. In turn, this means we often need to handle some extra validation for the data that comes in to our objects.

This is a lightweight post on handling your incoming values effectively by normalizing them as soon as possible. It's a simple guideline worth keeping in mind which will help you keep your code easier to reason about.

He gives an example of a HtmlClass object instance that can take in either a single string or an array of strings. With this structure he shows the complexity it would add for methods like toArray and toString. Instead he recommends normalizing the value in the constructor, making it an array if it's not already. The the code required in the rest of the class to use/translate it is much simpler.

On the HHVM blog there's a post talking about some of the updates they've made with array handling in Hack to help make it more efficient and overcoming some of the challenges in how they're being used.

Arrays are the ubiquitous data structure in PHP, used to represent everything from lists, associated lists, sets, tuples, or even a bag of data. This flexibility itself makes it challenging for Hack to understand how an array will be used. [...] If this was the only problem with PHP arrays, then the solution would be “simple”; make the type checker smarter (something we are working on). However there are a number of other semantic details around arrays that are nearly impossible to analyze statically.

They talk about some of the issues a bit more specifically including:

• indexing of non-existent keys
• key coercion
• arrays containing references

They also talk about some of the legitimate use cases for arrays over the collections Hack offers, mostly do to with the values they could contain. The post ends with links to some of the other future improvements to the array handling in Hack and a look further out and their vision of replacing PHP arrays with Hack arrays and moving collections to a runtime library.

In his latest post Matthias Noback talks about a problem common to Symfony bundles (and, well, software in general) - dealing with backwards compatibility and breaks that could be introduced with new changes.

With a new bundle release you may want to rename services or parameters, make a service private, change some constructor arguments, change the structure of the bundle configuration, etc. Some of these changes may acually be backwards incompatible changes for the users of that bundle. Luckily, the Symfony DependenyInjection component and Config component both provide you with some options to prevent such backwards compatibility (BC) breaks.

He breaks the post up into a few different kinds of backwards compatibility breaks that could happen and code examples of each:

• Renaming things
• Changing visibility
• Changing values

Each topic also includes methods for preventing issues with older users who maybe aren't using the new features. This includes things like sane default values for new settings, renaming services and creating new extensions for working with new properties.

The SitePoint Web blog has posted an interesting article sharing something called The Code Manifesto. The "code" referenced here isn't so much related to the actual code developers write as it is the conduct they follow in their relationships with others (on a professional level).

The tech industry has a rather bad reputation. Stories of discrimination, disrespect, sexism and outright mistreatment aren’t exactly hard to come by. [...] In an industry ostensibly aimed at helping everyone to reach their potential, it’s clear that when it comes to issues of equality and respect, the tech world has a long way to go. Kayla Daniels is one person working to try to change this situation. A North Carolina PHP developer, Kayla is behind The Code Manifesto, a list of values she hopes can be a small step in the right direction.

Among the points made in the manifesto are things like:

• Discrimination limits us.
• We are our biggest assets. None of us were born masters of our trade.
• Respect defines us. Treat others as you wish to be treated.
• Reactions require grace.

The Manifesto was born out of the frustration felt by Kayla in her work in technology. The six points are designed to help with two main things: respect and equality and contributing to the community...all as equals.

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.

Giulio Pons has a quick post with a code snippet showing how to grab the possible values for an ENUM or SET field on a MySQL database.

This function returns an array with the elements allowed in a ENUM or SET mysql field. This can be usefull if you’re making some automation and need to retrieve those values without writing them in your code.

The function uses the database's metadata to get the column information for a table and filter out the "enum" information from that. The column information includes the set of values possible and a few simple string handling functions make it easy to grab them. They could also be replaced by a regular expression or two to grab the same information more concisely.

Jonathan Snook is back today with more information gleaned from his voyages into the world of the CakePHP framework, this time focusing on setting up default values in your script.

If you've got a user seeing a form for the first time, normally the fields are blank. But there are times where you want to prefill fields with data or preselect a certain option. Setting a default value turned out to be really straightforward.

He includes the code to make this "really straightforward" functionality happen. It's a simple seven line affair to make the value for the Project's name set to "Default Project Name". It uses the special "data" variable to push the value into, which, as he mentions later, is best set with a "$this->data" format as is in his example.

Jonathan Snook is back today with more information gleaned from his voyages into the world of the CakePHP framework, this time focusing on setting up default values in your script.

If you've got a user seeing a form for the first time, normally the fields are blank. But there are times where you want to prefill fields with data or preselect a certain option. Setting a default value turned out to be really straightforward.

He includes the code to make this "really straightforward" functionality happen. It's a simple seven line affair to make the value for the Project's name set to "Default Project Name". It uses the special "data" variable to push the value into, which, as he mentions later, is best set with a "$this->data" format as is in his example.