Add composer.json
update composer.json
merged branch igorw/composer (PR #21)

Commits
-------

e595ddc update composer.json
1694527 Add composer.json

Discussion
----------

Add composer.json
fixed composer.json file
Using array_key_exists for raw instead of isset. Adding coverage.
merged branch mtdowling/ee0cdaa4ad6e3cbab25227785f49a75b9fd828f4 (PR #18)

Commits
-------

a78e1f7 Using array_key_exists for raw instead of isset. Adding coverage.

Discussion
----------

Adding test coverage for raw

---------------------------------------------------------------------------

by igorw at 2011/08/16 07:25:29 -0700

Thanks, one minor thing. The naming is inconsistent with `testOffsetGetValidatesKeyIsPresent`. Key vs Identifier.

---------------------------------------------------------------------------

by mtdowling at 2011/08/17 12:16:16 -0700

I corrected the naming inconsistency and modified the getRaw() method to use array_key_exists instead of isset.

---------------------------------------------------------------------------

by igorw at 2011/08/17 13:56:53 -0700

Please, `testRawWithNullValue()` instead of testing two things in one test.

---------------------------------------------------------------------------

by mtdowling at 2011/08/17 14:08:25 -0700

Done.  Used the same naming convention as testOffsetGetHonorsNullValues().

---------------------------------------------------------------------------

by igorw at 2011/08/17 14:56:57 -0700

Looks good to me.

---------------------------------------------------------------------------

by fabpot at 2011/08/18 10:15:48 -0700

Can you squash your 3 commits? Thanks.

On a side note, what about using `array_key_exists()` in `offsetExists()` too?

---------------------------------------------------------------------------

by mtdowling at 2011/08/18 11:05:54 -0700

Sure thing. I'll try to figure it out and update the pull request.

I'm not sure about changing `offsetExists()`... Calling `isset()` on a null value returns false.  Because `offsetExists()` is triggered by an `isset()` call, I think it should return false for keys that are set to null values so that it is consistent with standard array behavior.

```php
<?php
$a = array("a" => null);
var_export(isset($a["a"]));
```
outputs `false`

---------------------------------------------------------------------------

by igorw at 2011/11/08 04:55:26 -0800

I would keep the isset() in offsetExists. If you need help with the squashing, send me a private message here on github.

---------------------------------------------------------------------------

by mtdowling at 2011/11/08 19:23:52 -0800

Sorry that took so long.  I squashed it into one commit.  Let me know if that doesn't look right.
Added autoloading info in composer.json
merged branch stof/patch-1 (PR #22)

Commits
-------

4dfc000 Added autoloading info in composer.json

Discussion
----------

Added autoloading info in composer.json
Added constructor arguments.
merged branch marijn/feature/constructor-arguments (PR #23)

Commits
-------

2bf06b5 Added constructor arguments.

Discussion
----------

Added constructor arguments.

When creating dedicated containers with only a handful of parameters it can be nice to have constructor injection.

```php
<?php

$pimple = new Pimple(array('secret' => 'fabp0t'));
```

---------------------------------------------------------------------------

by igorw at 2011-11-29T09:41:01Z

I don't see the need for this. Especially with silex extending it, I think it's better to keep the constructor empty. I can also see Pimple moving to a PHP 5.4 trait in the future (with a standard class using it), where defining the constructor would not make much sense.

---------------------------------------------------------------------------

by marijn at 2011-11-29T09:45:54Z

I'm not sure I follow your analogy: "*with silex extending it*". Could you elaborate?

I can understand it if you want to keep `Pimple` simple, however, I do think it's a valid use case...

---------------------------------------------------------------------------

by igorw at 2011-11-29T09:52:35Z

It was not an analogy at all, I'm referring to the "Silex\Application" class: https://github.com/fabpot/Silex extending the "Pimple" class.

---------------------------------------------------------------------------

by marijn at 2011-11-29T09:58:52Z

I understand, that's why I don't see what it has to do with this issue. I'm simply suggesting that `Pimple` (and indeed `Silex`) in some cases might benefit from constructor arguments.

As much as I'd love to see Pimple move to a trait, I'm not sure if anticipating for it at the moment is really viable.

Anyway, feel free to close this if you reckon this is too bloated :-)

---------------------------------------------------------------------------

by marijn at 2012-01-25T21:39:52Z

@fabpot do you have an opinion on this matter?

What can I do to make this merge-able?
Adds extend method
Check definition is actually a Closure
merged branch davedevelopment/extend-existing-services (PR #29)

Commits
-------

6677eeb Check definition is actually a Closure
7367dca Adds extend method

Discussion
----------

Adds extend method, allowing users to extend/customise object Closures

Kind of like an after filter for objects.

Use case:

Third party code is used to register an object, user wishes to add method calls to the definition, without loading it before it is actually required.

e.g. Add a custom loader to the Twig Service when using Silex

``` php
<?php

$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path'       => __DIR__.'/views',
    'twig.class_path' => __DIR__.'/vendor/twig/lib',
));

$app->extend('twig', function($twig, $c) {
    $twig->addLoader($c['my.custom.loader']);
    return $twig;
});

```

I thought about returning a Closure and the user having to reassign it to maintain consistency with the existing API, like:

``` php
<?php

$app['twig'] = $app->extend('twig', function($twig, $c) {
    $twig->addLoader($c['my.custom.loader']);
    return $twig;
});
```

But I can't think of a use case where you wouldn't want to assign it, so made the assignment part of the method.

Another option I considered would be to not require the original object to be returned in the extending Closure, but that would prevent people using decorators and such.

---------------------------------------------------------------------------

by stof at 2012-03-31T23:34:30Z

I like it. It seems far easier to use than the current way to do this by retrieving the raw definition and doing some work by hand to extend the definition
fixed phpdoc
[docs] add docs for extend and raw
[docs] enhance extend docs
change teerminology from object => service
merged branch igorw/extend-docs (PR #30)

Commits
-------

f0f0414 change teerminology from object => service
8e0f1bd [docs] enhance extend docs
6213e14 [docs] add docs for extend and raw

Discussion
----------

[docs] add docs for extend and raw

---------------------------------------------------------------------------

by igorw at 2012-04-01T15:58:22Z

Fixed.

---------------------------------------------------------------------------

by igorw at 2012-04-01T19:05:06Z

What are your thoughts on calling them services / service definitions?

---------------------------------------------------------------------------

by fabpot at 2012-04-01T19:12:58Z

I would like to avoid calling them services as we are not using this term anywhere else in the doc.

---------------------------------------------------------------------------

by igorw at 2012-04-01T19:16:12Z

I am suggesting changing the terminology in the whole doc.

---------------------------------------------------------------------------

by fabpot at 2012-04-01T19:27:20Z

I'm fine with this change but please, add a small sentence to explain what a service is.

---------------------------------------------------------------------------

by igorw at 2012-04-05T23:00:58Z

I have changed it in the whole doc.
Fixes #32 - Better practice in twig extend example
Attempt to clarify the need to re-share extended services