BUG or INTENTION: ServiceManager::has() does not consider delegators and lazy services!

[Frank Hein]

I consider this a bug. But because it's so obvious, it may be intention.
I could fix that. Please advice.

[Marco Pivetta]

This is intentional: * Lazy services are just a special kind of delegator * Delegators can only work if a real service is defined

…

On 16 Jan 2018 01:36, "Frank Hein" ***@***.***> wrote: I consider this a bug. But because it's so obvious, it may be intention. I could fix that. Please advice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#228>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakFflr3dFspn1hxp8xyOtVlcld28Iks5tK-8mgaJpZM4RfGZn> .

[Marco Pivetta]

May be worth adding a scenario that solidifies this assumption. On 16 Jan 2018 07:12, "Marco Pivetta" <[e-mail]> wrote: This is intentional: * Lazy services are just a special kind of delegator * Delegators can only work if a real service is defined

…

On 16 Jan 2018 01:36, "Frank Hein" ***@***.***> wrote: I consider this a bug. But because it's so obvious, it may be intention. I could fix that. Please advice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#228>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakFflr3dFspn1hxp8xyOtVlcld28Iks5tK-8mgaJpZM4RfGZn> .

[Frank Hein]

Factories only work, if they are invokable. This is checked when requested also. Isn't that similar to delegators?

[Marco Pivetta]

A factory is supposed to instantiate a service (the assumption is "factory exists, therefore service exists"), but delegators only map over previous service definitions, so the service is not guaranteed to exist without a factory, abstract factory or alias already existing.

…

On 16 Jan 2018 20:06, "Frank Hein" ***@***.***> wrote: Factories only work, if they are invokable. This is checked when requested also. Isn't that similar to delegators? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakFRnBSoUaNlAR1BmQepvHcijJ2A7ks5tLPM-gaJpZM4RfGZn> .

[Frank Hein]

It is not checked that a factory is able to create a service currently. The answer (true) you might get from has() does not grant that you can actually successfully get() that item. Does that behaviour conform to PSR-11?

It is quite difficult for me to understand, what the difference is. A factory key relies on a proper factory setup. A delegator key relies on a proper delegator setup (which again relies on properly defined factories). They both have to assume much , because nothing gets checked at configuration time.

Two possible solutions: Accept the current state and check delegates also (in has()). This would be for consistency (with factories) but would not comply to the standard. Or: Check at configuration time, whether the supplied factories and delegators are valid enough specified to grant that people can get() the ServiceManager announces to have (has()). This would be compliant to defined standards.

Alternative: Discard has(). But this would break with the standard.

IIRC, parameter checks once where part of ServiceManager.

If the plans for ServiceManager do not include compliance to PSR-11, there seems to be no need to change container inheritance to PSR-11 (which would be a bc break).

Please advice.

[Marco Pivetta]

This was discussed multiple times in container-interop and in psr-11, as well as previously here in the ServiceManager component issues (probably zf2 at the time). The intent of `has()` is to report whether the container knows and predicts to be able to instantiate a service. `get()` may still fail due to I/O or misconfiguration. An example could be: * A db connection that is configured, yet cannot be established due to network failure * A service that depends upon other services that aren't mapped (some contains can prevent this via static analysis, bit with other complexity and/or performance issues) On 23 Jan 2018 07:19, "Frank Hein" <[e-mail]> wrote: It is not checked that a factory is able to create a service currently. The answer (true) you might get from has() does not grant that you can actually successfully get() that item. Does that behaviour conform to PSR-11? I find it difficult for me to understand, what the difference is. A factory key relies on a proper factory config. A delegator key relies on a proper delegator key definition (which again relies on properly defined factories). They both have to assume, because nothing is checked at configuration time. Two possible solutions: Accept the current state and check delegates also (in has()). This would be for consistency (with factories). Or: Check at configuration time, whether the supplied factories and delegators are valid enough specified to grant that people can get() the ServiceManager announces to have (has()). Alternative: Discard has(). :) IIRC, parameter checks once where part of ServiceManager. Please advice. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakBYWQZXDeJLiRf_awFdOYp6ZBP4xks5tNXnhgaJpZM4RfGZn> .

[Frank Hein]

Ok. So sm doesn't predict to have a delegator?

[Marco Pivetta]

No, that's really just decoration happening during service creation.

[Frank Hein]

F***, of course you are right. That was a stupid one. RTFM. Sorry ...