Thanks for that work, still I'm conflicted: indeed, that's a problem that we can't define arrays for now. But this solution is only partial: it works only for non-indexed and non-empty arrays.

So there's confusion with that solution, because users might think that it's possible to define arrays, whereas it's very restricted.

Anyway that's a fundamental problem, your solution could be merged for a 3.x version. For 4.0, I'd like to fix this definitely (don't know yet what's the best solution for that).

I prefer this one to be honest:

parameters:
    value1: 42
services:
    service1: ~

In 3.x it's possible to create method like $builder->addValueDefinitionsFromFile().

Container without arrays is very restricted for me. For instance, I cannot define list of emails for reports. Current format doesn't allow me to call some method twice. So I cannot define dependency neither

$reportCommand->addEmail('[email protected]');
$reportCommand->addEmail('[email protected]');

nor

$reportCommand->setEmailList(['[email protected]', '[email protected]']);

I prefer this one to be honest:

parameters:
    value1: 42
services:
    service1: ~

That's what I was thinking for 4.0. It's less "simple", but at least it will allow to offer 100% functionalities.

it works only for non-indexed and non-empty arrays

My point is you probably don't need assoc arrays since you can write

value1.key1: 42
value1.key2: "abc"

+1, totally right

but there is no way to create lists at all: current format doesn't allow me to call some method twice. So I cannot > define dependency neither

$reportCommand->addEmail('[email protected]');
$reportCommand->addEmail('[email protected]');

nor

$reportCommand->setEmailList(['[email protected]', '[email protected]']);

Yes I'm facing the same limitations, that's why I want to move 4.0 forward.

So to sum up, OK to merge this feature in 3.4 while waiting for a better solution for 4.0.

I'll do it later I can't right now.

Thanks

This is now merged in the 3.4 branch (manually merged), thank you for updating the docs too.

FYI v3.4 is now published (http://mnapoli.fr/PHP-DI/news/04-php-di-3-4), thanks again

There is a typo: "Note that the arrays have to be non-indexed", you wanted to say "indexed non-empty".

Right I forgot about non-empty. However they need to be "not (string) indexed" too, i.e.:

foo:
  bar: baz
  bim: bam

is not possible, whereas this works:

foo:
  - baz
  - bam

Maybe "non-indexed" is not really appropriate, do you see another way of putting it?

Well, "indexed" means numeric keys for me, "string indexed" sounds weird. You can replace it with "list of values", for instance.

Thanks I read the official doc and the proper terms are indexed VS associative array.

So I edited the sentence to:

Note that the arrays can't be associative arrays, and must not be empty.