On his site, Daniel Gomes has written up an article that makes a suggestion about working with objects in PHP. In it, he suggests performing a deep copy of them rather than just cloning them into a new variable.

As you know, PHP has a well-known clone keyword that shallow copy all of the object’s properties. So under the hood what it does is to create a new Object with the exact same values of that object properties – unless you change its behavior by implementing the __clone() function in your class.

This behavior seems what we expected. However, it might give “weird” results if the object that you are cloning contains properties that are objects.

He gives an example of this "weird" result when cloning an object that has a model property containing an instance of a CarModel class. He shows the hash IDs for the objects (different), the model properties (the same) and how changing one changes the other. This could lead to some unintended consequences so he suggests a deep copy instead using a handy library. He finishes the post with example code using this library and the resulting hashes/value differences.

Rob Allen has a quick post to his site that could help out Composer users when they need to transition to a git copy of a repository rather than an export.

I'm adding a new feature to ZF's Problem-Details component and it's easiest to do this within the context of the application I'm developing.

The component lives in vendor/zendframework/zend-problem-details and was installed using composer require so doesn't have its own git repository as the distribution zip file was used to install it.

He shows how to use the built-in --prefer-source option for Composer to pull down a clone of the repository rather than the copy. This allows you do develop right in the same environment without having to re-clone the repository somewhere else and work from there.

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

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.

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.

So you've been working on your own code for a while now but have been hearing about Github and how it makes it simple to contribute to other projects too. Maybe you haven't found the time to get into git and Github yet. Well, this new post (a reprinted article from php|architect) to Lorna Mitchell's blog will tell you all you need to know.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

She covers all you'll need to know to get in and get going with Github - forking a current repo (she uses Joind.in as an example), cloning your fork, making updates and submitting them as a pull request back to the main project. There's also some things about general git topics like branching, merging from the upstream source and using "git log" to view the changes.

As is mentioned in this new post to the CodeIgniter project's main site, their wiki has made a move. You can now find it on github.

In addition to having the convenience of existing as a git repo itself, moving this content to GitHub will help distinguish EllisLab and Reactor created content from community managed resources. It will also reduce the attraction of spammers to the CodeIgniter.com web site, as the wiki was a common location used by spammers and vandals to get content on our site that was less likely to be found and moderated than the frequently visited forums.

You can make changes if you see something incorrect by cloning the repo and making changes to the wiki repo and putting in a pull request.

The announcement has finally come - the PHP project has officially moved to git!

The migration of the PHP source code from Subversion to Git is complete. You can clone or fork the source from our GitHub mirror, and we also now support pull requests made via GitHub. The source is also available via git.php.net, and full instructions on cloning the php-src tree can be found at php.net/git. One immediate benefit is that future PHP release tags will be signed by the PHP development team. We will be releasing GPG keys for verification purposes in the next few days. More information on the migration and the new workflow can be found at the Moving to Git FAQ on the PHP Wiki.

This move does not include the manuals yet, but that's coming soon. Be sure to follow these steps if you'd like to contribute back via the git repository. This is a great move for the project and makes it even easier for developers to contribute their fixes and ideas back to the development group!

Joshua Thijssen has also posted a guide to getting started on his blog.

In this new post to his blog Stoimen Popov talks about calling the "destructor" method of an object and why doing it directly could lead to some issues - like not actually destroying the object before the script ends.

At the end of the script the interpreter frees the memory. Actually every object has a built-in destructor, just like it has built-in constructor. So even we don’t define it explicitly, the object has its destructor. Usually this destructor is executed at the end of the script, or whenever the object isn’t needed anymore. This can happen, for instance, at the end of a function body. Now if we call the destructor explicitly, which as I said I’ve seen many times, here’s what happen. As you can see calling the destructor explicitly doesn’t destroy the object. So the question is...how to destroy an object before the script stops?

He points out that one way to "destroy" an object is to null it out and remove the structure from memory. This is tricky, though, because a clone of the object will still exist in memory, just not the original.

Fabien Potencier has made an announcement on the Symfony Blog today about all the availability of previous Symfony versions on github.

symfony1 is well and alive and many developers are now using it for projects hosted on Git. But as the official symfony 1 repository is hosted on Subversion, it's not always easy to get things versioned easily. As of today, this becomes much more easier. If you are using Git and symfony1, you can now use the official symfony1 Git clone.

There are branches for each of the major 1.x releases as well as tags for some of the minor releases. You can, of course, still access the latest packages directly via the symfony website.