DI\object() should not extend the previous definition by default

[mnapoli]

This is a BC break planned for next major version (5.0).

The problem is that we want to add decoration and definition extension, but that already exists for DI\object() today and it's implicit.

The reason it works implicitly today is to take advantage of autowiring/annotations as much as possible, for example:

class Foo {
    public function __construct(Bar $bar, $string) …
}

return [
    'Foo' => DI\object()
        // I only have to define the non type-hinted parameter
        ->constructorParameter('string', 'Hello world'),
];

If we add definition extension and decoration as a main feature with explicit syntax addition (e.g. adding items to arrays, etc.), should we make it also explicit for objects. This is a BC break.

return [
    'Foo' => DI\object()
        ->extend()
        ->constructorParameter('string', 'Hello world'),
];

Without ->extend() the definition is considered as a complete override of any previous existing definition (defined either in a file, autowiring or annotations… doesn't matter).

Pros

• it's explicit whether you extend or not
• you can choose not to use it to replace the previous entry (which is currently impossible)
• you can control what you extend (->extend('some_other_custom_entry')) like in Symfony for example
• it would be more consistent with other ways to extend definitions
• it would solve side-effect/bug DI\object()->method() does not support calling same method twice #193

Cons

• BC break: people have to update their config files
• syntax more verbose to extend a previous definition

[mnapoli]

I have finally decided not to introduce this change.

I have implemented it in #244 but after writing tests and playing with it, I realized some difficult problems where surfacing which meant that the level of complexity was much higher for the user. Even I had trouble writing very simple object definitions with the patch.

Regarding #193 this can be fixed regardless of this.

Regarding extending another entry like in Symfony, I have never met that use case yet (it's a very rare need): at worst we have to write twice the same definition, which is acceptable compared to adding complexity to every other use case.

Regarding "you can choose not to use it to replace the previous entry (which is currently impossible)" it is still possible to introduce an option to DI\object() to make that possible.