sprintf('$references = %s;', var_export($services, true)); ?

(Sorry, moved my comment here, as it seemed more appropriate)

@Taluu I tried it and in fact we only need a string map here, whilevar_export dumps Reference objects. Also looping over references is actually needed for generating the getter code so I think it can be kept as is, unless another existing helper exists for such

More a question of tastes and all, but instead of several concatenations, I would have used a nowdoc instead :

<?php// ...$hasserCode = <<<'EOD'$references = ...EOD;

Not excluding a call to sprintf afterwards, of course

it should not extend IteratorArgument. A LocatorArgument isnot an IteratorArgument (something checking for iterator arguments should probablynot be triggered for locator arguments)

It was a mistake, fixed.

doesn't have to be only references - the yaml loader currently supports any kind, which is nice I think - same for the xml loader

Does that mean$v = $v instanceof Reference ? $v : new Reference($v); should be used, or do you have something else in mind (keep scalars, parameters)?

Nope, the values can really be anything, references or arrays or scalars

GivenContainerInterface::get() must return an object, scalars should be returned bygetParameter(), right?

should implement ContainerInterface to me

Should we mark it as internal also so that we discourage it from being used in type hints?

should implement ContainerInterface to me

I hesitated to, sounds good to me. However, since yaml/xml file loaders can return references, should we just ignore their invalid behavior and use the one passed toServiceLocator::get()?
Also, should it make somenoop for e.g.get/setParameter(), or should it truly implement that?

Maybe we could make it implement the ArrayAccess interface. It would allow consumer interfaces to usearray|ArrayAccess as a type hint and use it like an array.

@nicolas-grekas : Just to be sure: You're talking about PSR-11'sContainerInterface, right?

Yes psr-11 will solve part of the problem (it solves the coupling with the symfony framework).

But let's say we use this feature for some symfony component (Form Types could be an example), if i want to use this component outside the symfony framework I would need to : require an psr-11 container, instantiate it with the services I want and then pass it to the component when I could just use a PHP array.

You're just looking for psr-11

PSR-11 is still about DI containers. It semantically couples the code with dependency injection container concept. This is odd: I don't want to know whether it is container or simple array-like map of "command handlers". DI container is just specific type of a map.

@jvasseur@unkind you're missing eg exceptions - the wording about them in PSR-11 is a requirement here also. ArrayAccess is not an interface - it's just an magical incantation for the engine.

to use this component outside the symfony framework I would need to : require an psr-11 container

???: thiswould be an implementation of PSR-11, so you'd need nothing else really.

I'm talking about using a component outside of a DI container so yes you would need to require one.

you're missing eg exceptions - the wording about them in PSR-11 is a requirement here also

What exactly do we miss? You shouldn't access array field without checking whether it exists. So you won't face theNotFoundException (the only checked exception in PSR-11, btw) or your code is just broken.

the in_array part looks wrong to me - keys must be the ony way to reference values

keys must be the only way to reference values

given that keys should be the only way to reference values, instead of hasser+getter, I'd suggest generating a singleClosure[], keyed by "public" service name

That does not help that much. But now I realize that I've missed something in this PR. This allows to inject both services and parameters, right? But a service locator is really about giving access to services only, not parameters. Any use case for having parameters as well?

That's PSR-11 - return type of "get" is mixed for this reason - same as eg Pimple ;)
I see no reason to forbid non-objects - that won't provide any technical benefit (even if I won't use that much myself).

Please see#21553 (comment). There's no explicit notion of parameters here, only services toget() but services can be any value. I have no strong opinion about, but that's PSR-11 compliant and I don't see any reason to forbid it in fact.

Let me be very clear: I don't care about PSR-11. Let's go back to the basics instead. A service locator must return services. So, let's do that.

And as far as Pimple is concerned, please keep in mind that this is a toy, a joke, not the holy grail of dependency injection, so mentioning it here is pointless :)

Docblock and tests updated to expect only references.

It now throws on non-reference values

Reference[] + validity check in the constructor? maybe also in loaders if that can provide more useful error messages?

done