-
Notifications
You must be signed in to change notification settings - Fork 89
Added setCreationOptions() to InvokableFactory #91
Added setCreationOptions() to InvokableFactory #91
Conversation
Sigh. This might work for Any suggestions? |
Nooooo not this one ;(. Don't bring back this one. Any way, you need to call build instead of get to create new instances at each call. |
…uck-types for forward compatibility
@bakura10 Unfortunately SM2 doesn't have a build method. I'm trying to make this forward compatibility thing work. |
Right, for forward compatibility I've changed AbstractServiceManager to duck-type the old
Not pretty, but the best I can think of. |
/me want to create a v4 without compatibility :o. |
Y'know after struggling with this for the last few days I couldn't agree more :) |
It is. If
Migration is important. But the nice part is that we only have to think about the current major version to the next, so it should only come up rarely. |
__CLASS__, | ||
(is_object($creationOptions) ? get_class($creationOptions) : gettype($creationOptions)) | ||
)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The above are unnecessary, as $creationOptions
is type-hinted to array
in the signature. Since that's what's defined in the interface, we can just remove the functionality.
I'll take care of it on merge.
@bakura10 Also, this is not bringing back the |
Added setCreationOptions() to InvokableFactory
I've run into a problem where multiple calls to
get('foo', $options)
on a plugin manager are not setting the options on subsequent calls. I'm an using an alias toInvokableFactory
, as recommended in the v2-v3 migration docs.This PR addresses that for v2 by adding the
MutableCreationOptionsInterface
toInvokableFactory
.Note that this only works when the plugin manager has been marked
$shareByDefault = false
. I am unable to determine if that is expected behaviour.