Ref #35, #16 and #5

• [x] Create the snapshot interfaces
• [x] implement the recursive
• [x] Refactor how the object snapshots are built
• [x] Refactor how the array snapshots are built
• [x] Refactor how the collection snapshot is built
• [x] Reflect changes on the Set
• [ ] Implement "comparator"
• [ ] Tests

Merry christmas @krichprollsch and @lunika, if this works as it should... :heart:

Basically, removing all traces or dependencies towards Reflection for an ObjectSnapshot. Need to create more tests though with actual objects (see https://gist.github.com/Taluu/2ed4d1d71d5c0db291c4#gistcomment-1657274)

• [x] Remove Reflection stuff
• [x] Add some tests for private / protected properties

It's a little bit hackish though, even though it is still far more optimized like this.

Should fix #19 and probably fit with #21. But it is not really recursive, as there's no guarantee that an array with numerical indexed elements are collections, and if they are, if they have the same type of primary key.

• [x] Add a ward against trying to normalize a data that is already a snapshot
• [x] CollectionSnapshot
• [x] Unit Tests
• [x] Use Symfony's PropertyAccess component
• [x] Allow to pass some options into the CollectionSnapshot (like a directive to tell the snapshot which sub-snapshot to use for each values of the collection)

Comme décrit ici, lorsqu'on remplace les id par des lettres, on a une 500 au lieu d'une 404. A moins que ça soit le standard django? Quoi qu'il arrive, bug ou non, c'est pas prioritaire.

Now, we may set a different SetClass to use when calculating the diff between two snapshots

• [x] Add a SetInterface
• [x] Alter AbstractSnapshot to declare a setClass property
• [x] Alter Set to add some protections while the set `is not computed yet
• [x] Fix the tests
• [x] Counter the BC Break on the Set class

Some BC Breaks were introduced though (like the suppression of the constructor of the Set class and the need to call explicitly the compute method on the set)

Fixes #5

The raw data which is set in the AbstractSnapshot can be wrong.

Example : on objects, it may return the new state (references, etc) instead of the state it was when it was snapshotted.

I added this property in order to be able to act on the real data if I ever needed it, like on the diff. I should try to find another way to do that, without really relying on the "raw state".

Because Shippable is a CI service that is cooler (and faster) than Travis-CI.

But it suffers some problems at the moment (coveralls integration is not complete, and the tests results are somewhat disappointing even though it is said that everything is fine). And also because I do not have enough rights on the repo right now to use Shippable.

So the point is, this should not be merged before everything is settled.

Fixes #17 : Now, a ChangeInterface is available to not be delimited by an AbtractChange but something more open (like, in my case, having to extend Set and allow to fetch the "old" data and the "new" one)

Allow to use a different Set (an extension, or something like that) in the built-in snapshots rather than only the built-in Set.

Currently, if you want to use something else, you have to reimplement the diff method of AbstractSnapshot... Even if all it does is just changing the class used.

Occur on instantiate: $snapshot = new ObjectSnapshot($object);

According to me in ObjectSnapshot ligne 48, $object is missing. $this->data[$reflProperty->getName()] = $reflProperty->getValue($object);

Instead of only see what has changed, i should soften up the Set to also accept different array sizes when computing the changeset, so it shows what has added and removed.

Just opening an issue so that I can check it up later. Any comments on how I should proceed are welcome.

Which wold be used to snapshot data with a notion of priority. This would remove the call to any normalize in built-in snapshots and thus remove this method for the AbstractSnapshot.

As this may be a BC Break, I'm tagging this for 2.0.

Because 5.4 is now EOL for a while. Should bump to 5.6 (.. or 7 ?). As we are trying to stick close to [http://semver.org](Semantic Versionning), this should be considered on next major bump ("version 2.0")

I'm not a huge fan to inject a setClass into the AbstractSnapshot. I think it should be a SetInterface object, as an DIC would like to have.

Just writing this issue to think about that later.