Remove dependency on Pimple

[aik099]

Closes #21

[aik099]

@fabpot is it ok (from licensing point of view) to copy Pimple code under different namespace inside the project (this is what's done in this PR) to avoid conflicts when installed alongside with Silex?

I've kept licensing comment in each Pimple file intact.

[fabpot]

From a licensing point of view, I don't have any problems. From a "technical" POV, I don't like this idea all.

[aik099]

From a "technical" POV, I don't like this idea all.

Any idea on solving? Having dependency on DIC (e.g. Pimple) creates a problems, when another library (e.g. Silex) is using incompatible version of same DIC.

[fabpot]

I have another idea. A simple solution would be to have a different package name; that would be enough as the class names are very different between Pimple 1 and Pimple 2/3. So, I propose to create Pimple 4, which would be the same code as Pimple 3 but with a different package name. Then, I would depend on Pimple for Silex, and everyone should then do the same. That way, you could use Pimple 1 and Pimple 4 in the same project.

[aik099]

Sounds interesting. The Pimple 2.1.1 however does following in Pimple.php file (https://github.com/silexphp/Pimple/blob/v2.1.1/src/Pimple.php):

class_alias('Pimple\Container', 'Pimple');

So if Pimple 1 (from Silex) and Pimple 2.1.1 are used on one project, then it could be tricky, because:

1. both are from same \ namespace and I have no idea how Composer auto-loader would prioritize them
2. if Pimple 2.1.1 code is executed first then it creates Pimple class
3. if Pimple 1 code is executed first, then it creates Pimple class and class_alias call inside Pimple 2 might even result in a notice

[fabpot]

I'm only talking about making Pimple 1 and 4 compatible, which should be enough for the vast majority of the projects out there.

[aik099]

Then every project should migrate to that new pimple-4 package to allow installation together. Of course except Silex 1.

And probably pimple/pimple package needs to be marked as abandoned in favor of new package that would have replace: ... in it's composer.json.

[aik099]

@fabpot , any update?

[aik099]

@fabpot , any update?

[aik099]

@fabpot , any update?

[fabpot]

So, we've tried to make it work and that's just too much work, we gave up. I'm still not very happy with coy/pasting but if that's the only solution...

[aik099]

So, we've tried to make it work and that's just too much work, we gave up.

You mean you've tried to create a package on Packagist with Pimple 1.0 only and that didn't work?

[adambro]

Doing copy-paste for such small thing as Pimple is fine IMHO. It reduces coupling and increases cohesion, which is good thing for a library.

Other option would be to depend on container-interop/container-interop package and let user choose DIC. I guess it's more complicated though.

[aik099]

Other option would be to depend on container-interop/container-interop package and let user choose DIC.

Would this help? Now I'm depending on Pimple 1. After change I will depend on container interop and still depend on Pimple 1 it uses, nope?

[aik099]

The failing test on HHVM is due sebastianbergmann/phpunit#2109 bug of PHPUnit. Apparently HHVM doesn't like when DOMDocument class objects are serialized, but normal PHP versions just do it and no error happens for them.

[aik099]

@fabpot , any update on this?

[fabpot]

I suppose copy/pasting is the way to go. I just don't have time to investigate other solutions.

[aik099]

OK.