New Releases

83 views
Skip to first unread message

pmjo...@gmail.com

unread,
Dec 21, 2015, 3:11:16 PM12/21/15
to aur...@googlegroups.com
Hi everyone!

We have released these new package versions:

Aura.Di version 3.0.0-beta2, with these changes:

This is the second beta release of this library, and likely the last before a stable release (barring unexpected feature changes and bugfixes).

- (BRK) _Container_ methods `newInstance()` and `get()` now lock the _Container_ automatically. (See note below.)

- (CHG) `$di->params` now allows `null` as a parameter value.

- (ADD) ContainerConfigInterface

- (ADD) Better exception messages.

- (DOC) Add and update documentation.

* * *

Regarding auto-locking of the _Container_ after `newInstance()` and `get()`:

This prevents errors from premature unification of params/setters/values/etc. in the _Resolver_. As a result, do not use _Container_ `newInstance()` or `get()` before you are finished calling `$params`, `$setters`, `$values`, `set()`, or other methods that modify the _Container_. Use the `lazy*()` equivalents to avoid auto-locking the _Container_.


Please let us know if you have any questions, comments, or concerns about this or any other release. And thanks, as always, for supporting Aura!

--
The team at the Aura project
http://auraphp.com

Hari K T

unread,
Dec 21, 2015, 9:46:15 PM12/21/15
to aur...@googlegroups.com
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 :-( .


Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

--
You received this message because you are subscribed to the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to auraphp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paul M. Jones

unread,
Dec 22, 2015, 12:07:00 PM12/22/15
to aur...@googlegroups.com
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


Hari K T

unread,
Dec 22, 2015, 11:48:41 PM12/22/15
to aur...@googlegroups.com
Hi Paul,

Thank you for the reply. I will write in-line so I don't miss anything.

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.

I get your idea, but I am not confident enough to push it unless you see some of the drawbacks in it. Eg : common configurations.
 
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?

I get the problem, and I know the answer can be yes / no depends on what we are expecting. So the only thing what a user could have done is check the code and see what went wrong. And you have already found where the issue is.
 
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?

You have specified the problem and I believe this can be implemented in some other way also. ( I may be dump and can be wrong :-) )

$di->params , $di->setter etc is calling

https://github.com/auraphp/Aura.Di/blob/c60281ebf1c2366c1bb1eb5d52447f2cd707fe17/src/Resolver/Resolver.php#L95-L99

and store the values.

The resolve method is the part where the newInstance method is called.
So the idea is when a call to params or setter is made remove the unified classes

https://github.com/auraphp/Aura.Di/blob/c60281ebf1c2366c1bb1eb5d52447f2cd707fe17/src/Resolver/Resolver.php#L260

and also the instances made in the service if there is no lock defined.
Not sure if that is a good idea, but better than locking I guess.


For what it's worth, I won't make a stable release until we talk this out.

Thank you

Hari KT

Hari K T

unread,
Dec 22, 2015, 11:53:15 PM12/22/15
to aur...@googlegroups.com
Hm, my answer brings another issue.

We may only want to reset for the class definition that is being modified. Not every instances.

I still want to think on it, if there is more problems coming in the scene .
Reply all
Reply to author
Forward
0 new messages