In this new tutorial on the TopTal.com site author Agustin Villalba takes an in-depth look at how objects and references are handled in memory by the PHP language.

In this article, I will talk about how object and variable references are controlled in memory, since this is an issue that can generate discussion and differing opinions. One question to ponder is: “By default, are objects passed by reference or by copy in PHP?” I’m going to talk first about what references are not in PHP; secondly, I’ll discuss what they are, and finally, I will examine how the garbage collector works in PHP.

He starts with a quick comparison between objects and references (since they're slightly different). He then covers what things are and aren't references in PHP and some examples showing what they are in either case. Code examples and visuals are included showing how things relate. The post wraps up with a look at how garbage collection works with objects/references and a few closing thoughts about how the collector chooses which to clean up.

On the Exakat.io blog there's a post continuing on from a "dos and donts" article about programmer practices. In this new post cover some of the rules in a bit more detail from the original article.

Last week, I ran into ‘PHP Dos and Don’ts aka Programmers I Don’t Like‘ on reddit’s PHP group. It features a list of 11 points that the author hates finding in PHP code. [...] The most interesting point is that coding references are used to asses code. They may very well be automated, thanks to static analysis. I thought it was a good challenge for Exakat.

The list covers several of the rules in the list, providing a brief explanation (and a bit of how it relates back to PHP) including:

• Unnecessary casting
• Extra bracket and braces
• Lack of coding standard
• Too many nested if statements

He ends the post with a bit of detail about how the Exakat service is checking for these "failures" in it's newer "RadwellCode" report. He even gives the scores of some of the more well-known and used PHP projects including the Zend Framework (v1.12), WordPress, Composer and even Exakat itself.

As is mentioned in this new post to the Laravel News site, there's a handy Laravel Cheat Sheet that's been published to help keep relevant Laravel information at your fingertips.

The Laravel Cheat Sheet is a new project from the EST Group that shows you many of the Laravel features from a filterable web app. For those that have used Laravel for a few years, you may notice the similarities to Jesse O’Briens.

Jesse hasn’t had time to keep his version up to date which left an opening for this new one. However, I’m disappointed in the similarities. Even though both are open source it just feels odd to me that this one looks so much like Jesse’s.

You can view the project directly (via GitHub pages) or grab the source if you'd like to check it out.

Johannes Schlüter has a post to his site that talks about references in PHP 7 and how they're "still bad" based on some of his previous findings.

I'm known for telling "Don't use references" (also as video) as those cause different problems (i.e. with foreach) and hurt performance. The reason for the performance loss is that references disable copy-on-write while most places in PHP assume copy-on-write. Meanwhile we have PHP 7. In PHP 7 the internal variable handling changed a lot among other things the reference counting moved from the zval, the container representing a variable, to the actual element. So I decided to run a little test to verify my performance assumption was still valid.

He includes his testing code that calls a function (strlen) in a loop and compares the handling against two methods, one passing by reference the other not. The results are shown in time taken to execute. He compares the results for PHP 5 and PHP 7, noting that PHP 7 is marginally better when passed by value, by-reference is still about the same.

Ben Ramsey has shared an interesting issue he's come across when installing packages via Composer where it installed a different version than expected when he ran an install. The problem turned out to be from an unexpected place.

For applications I control that are not distributed to the public, I like to hard-lock my Composer dependencies to a specific version. [...] Sometimes a library has updates that haven’t yet been released, and I need to use these right away. Composer allows me to specify the specific commit I want to use for a library. In this way, I can hard-lock a dependency to a specific state, even when there is not yet a release for the changes I need. This has worked well until today, when I tried to do a fresh composer install. After installing, one library contained files and methods that I did not expect. It turns out Composer was grabbing the HEAD of dev-master instead of the specific commit I referenced.

After some investigation into his "composer.lock" file's contents, he found the issue: a problem with the way that BitBucket handles the distribution zip files Composer requests. In his example, the zip file was of the HEAD on the repository, not of the specific commit (GitHub doesn't have this problem). His solution was using the (slower) "--prefer-source" option to grab the correct commit contents...not an ideal solution but it does what he needs.

Nikita Popov has a new post, the first part of a series, talking about the internal handling of variables in PHP7 and how it has changed from the current/past methods.

My last article described the improvements to the hashtable implementation that were introduced in PHP 7. This followup will take a look at the new representation of PHP values in general. Due to the amount of material to cover, the article is split in two parts: This part will describe how the zval (Zend value) implementation differs between PHP 5 and PHP 7, and also discuss the implementation of references. The second part will investigate the realization of individual types like strings or objects in more detail.

He starts with an introduction to the "zval" struct type and how it relates to the "zvalue" union. He goes on to talk about reference counting on zvals and some of the reasoning/desire to change how these are handled. Finally, he gets to the zval handling coming in PHP7 and the fundamental change in zval handling - they're no longer "individually heap-allocated and no longer store a refcount themselves". This change has several advantages and including improved refcount handling and less pointers involved in determining the actual value. He includes an example of how this new zval structure is defined in PHP7 compare to the previous version too. The remainder of the post looks at other related issues including memory management, supported types and a major change to how variable references are handled.

Giorgio Sironi has posted his quite impressive list of articles he's published on the DZone.com site to his blog today. They cover a wide range of topics - everything from refactoring to design patterns out to, well, lots of other random topics.

From 2010 to the end of 2013 I have written a few articles each week on DZone. Here is the full list as a reference.

Some of the posts fall into different "series" categories including "Practical PHP Patterns", "Practical PHP Refactoring", "Practical PHP Testing Patterns" and "Lean Tools". There's some great content here - and lots of it - so be sure to check out the list and see if there's anything that catches your eye!

In this recent post over on DZone.com Giorgio Sironi takes a look at the "clone" feature of PHP - what it is, how it can be used and things to watch out for in its use.

Cloning is an operation consisting in the duplication of a data structure, usually to avoid the aliasing problem of having different code modify the same instance in inconsistent ways. In PHP, cloning can be accomplished in multiple ways - and in some cases it can be avoided altogether.

He talks some about how objects are passed around internally during the PHP execution and how you can tell if a function works with data by reference (from the manual). He then looks at the "clone" keyword and what kinds of things are duplicated from an object when it is used. He briefly touches on the "__clone" magic method for solving the "shallow clone" problem and how, possibly, serializing the object might be a better alternative for reproducing the entire object.

The PHPClasses.org site has posted a humorous look at the PHP language with several reasons why PHP is a "hobbit" (a Lord of the Rings series reference):

Sometime ago a user of the Quora site asked a question if there was a language war, which languages you support and why. Another user gave a very creative response comparing programming languages with characters of the Lord of the Rings story of JRR Tolkien.

There's six reasons listed in the post:

• PHP is Scripted C
• PHP is not Teaming with C++ Evil
• PHP is Not particularly Beautiful but it is Very Useful
• PHP is Not the Fastest Language to Execute but is Agile
• JavaScript could be a Hobbit too but Asynchronous Programming is a Hell
• PHP Success Causes the Envy of Others

If you're interested to see the thread where the idea for this post came from, you can read it here on Quora.

In a new post to his blog Lee Davis describes the enum conundrum - what's the right solution for effectively using ENUM-type fields in your data?

So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I’ve heard they’re evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.