I often need a shared service implemented by a class, but setup with unique parameters.
I can already handle that using the newly introduced build api. Pseudo code:
$service = $servicemanager->build($service, $myParamSet);
$servicemanager->setService ( 'my hopefully unique service name', $service);
... store and manage that name somewhow
In my code I have to manage my hopefully unique service name and what particular configuration is
associated with that particular name.
I propose, to let ServiceManager manage and maintain that.
The easiest way to provide that feature was, if an implementation of ServiceManager::get like
public function get($name, $options = null)
would comply to the standard. I actually do not know. In that particular case, documentation is not detailed enough. Are you still compliant with PSR-11 (or interop\container) if there is an optional parameter? I do not know. Explanation would be highly appreciated.
If get with an optional paramet would be ok, ServiceManager could easily verify, if that service with this parameter set was requested before and deliver the (already instantiated) instance, or produce a new shared service for that particular parameter set and return the id. The user can decide, if he wants to manage the retrieved id, or if he just wants to request the same service with the same parameters again and rely on the ServiceManager to deliver the shared instance on match.
I'd offer fast implementation. Including benchmarks.
Please read #224 first.
I often need a shared service implemented by a class, but setup with unique parameters. I can already handle that using the newly introduced
build
api. Pseudo code:In my code I have to manage
my hopefully unique service name
and what particular configuration is associated with that particular name.I propose, to let ServiceManager manage and maintain that.
The easiest way to provide that feature was, if an implementation of ServiceManager::get like
would comply to the standard. I actually do not know. In that particular case, documentation is not detailed enough. Are you still compliant with PSR-11 (or interop\container) if there is an optional parameter? I do not know. Explanation would be highly appreciated.
If get with an optional paramet would be ok, ServiceManager could easily verify, if that service with this parameter set was requested before and deliver the (already instantiated) instance, or produce a new shared service for that particular parameter set and return the id. The user can decide, if he wants to manage the retrieved id, or if he just wants to request the same service with the same parameters again and rely on the ServiceManager to deliver the shared instance on match.
I'd offer fast implementation. Including benchmarks.