Hi Hari,
> On Dec 21, 2015, at 20:46, Hari K T <
ktha...@gmail.com> wrote:
>
> Container locking .... Please don't lock automatically.
>
> I am using it without locking and need to modify the configuration values later.
>
> If a route is matched, add the configuration values .
>
> Eg : /api => Load the api related configuration.
>
> Locking the container automatically will block the functionality and will cause issues in the current project :-( .
First, I will opine that modifying the container once you pull objects out of it is probably unwise. As an alternative, you may wish to use series of containers: one for the initial entry point, one for APIs, one for non-APIs, etc. Once the initial entry point determines the route, it can then instantiate the more specific container for that route.
Having said that, I don't want to break your project. Here's the problem I ran into that drove this change:
- I configured object Foo, then called newInstance() before locking the container.
- I then changed the configuration for Foo, and called newInstance() again. The container returned the second instance using the first configuration, not the changed configuration.
That surprised me, and I'm the one who wrote it in the first place.
The problem is that the first newInstance() call triggers the "unification" process, where the resolver looks up the entire inheritance hierarchy and memoizes all the params, setters, etc. That means changes to the Foo params, setters, etc. will never be be honored once newInstance() (or get()) is called.
With that in mind:
1. Does that behavior strike you as surprising, unexpected, unwanted, etc?
2. If so, do you think it's worth it to prevent the user from getting the unexpected behavior? (Auto-locking was the second thing I tried; the first was to throw an exception on calls to newInstance() and get() if the container was not locked.)
3. Finally, can you think of ways of doing that, that are relatively easy to implement?
For what it's worth, I won't make a stable release until we talk this out.
Let me know!
--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php