Turning off auto-resolve by default

51 views
Skip to first unread message

Brandon Savage

unread,
Dec 1, 2014, 6:15:50 PM12/1/14
to aur...@googlegroups.com
Hello all,

In v2 of Aura.Di, we introduced an auto-resolution feature that would create objects if the DI container knew how. This creates a number of problems where the DI container determines it can create an object, but does so with incorrect configurations. Currently, by default, Aura.Di turns autoresolution on by default. It's my recommendation that this feature be turned OFF by default.

Turning it off by default will help users avoid these kind of configuration problems. It will also help newer users by having Aura.Di be explicit when they misconfigure it, instead of randomly satisfying its dependencies in an unpredictable way.

I have submitted a PR here: https://github.com/auraphp/Aura.Di/pull/76 It generally has Paul's blessing, but Paul isn't the only one with an opinion. Please share yours.

Brandon

Ian Littman

unread,
Dec 1, 2014, 9:46:41 PM12/1/14
to aur...@googlegroups.com
I'm for turning it off. But then again, I'm still using an older version of the lib that doesn't have it turned on anyway.

--
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.

Hari K T

unread,
Dec 2, 2014, 9:03:39 PM12/2/14
to aur...@googlegroups.com
Hi, 

So auto resolution seems nice, and was added in 2.0. Mostly I may be the one who pushed Paul. 

It seems to be right, but hard to figure out when debugging.

I don't like to remove the feature completely, but disabled seems nice. The idea of auto resolution was proposed for it seems lots of time to write the configuration. 

There is another issue here https://github.com/auraphp/Aura.Di/issues/74 ( What to do with singletons? ) .

If auto resolution is going to be disabled I propose we need a way to dump the configuration which help us to write the config .

Don't love to spend more time writing configurations :-/

Thoughts ?

Hari K T

unread,
Dec 3, 2014, 2:13:10 AM12/3/14
to aur...@googlegroups.com
So I made a simple dumper . 


May be we can improve to make things much simpler in Aura framework ? Your thoughts ?

Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

--

nyamsprod

unread,
Dec 4, 2014, 4:21:54 PM12/4/14
to aur...@googlegroups.com
I've been working with Aura Web Project lately and the part which is the most painful is the Config part. Anything to simplify this part is welcome.

Hari K T

unread,
Dec 5, 2014, 10:40:23 AM12/5/14
to aur...@googlegroups.com
Hi,
 
I've been working with Aura Web Project lately and the part which is the most painful is the Config part. Anything to simplify this part is welcome.


Let me know what you think about it .

Usage is 

vendor/bin/di-config-dump path/to/file.php

vendor/bin/di-config-dump path/to/directory

Thanks

Moshe Brevda

unread,
Dec 8, 2014, 4:04:28 AM12/8/14
to aur...@googlegroups.com
This creates a number of problems where the DI container determines it can create an object, but does so with incorrect configurations
 
Before forming an opinion, it would be helpful to have more of a grasp of the issues involved. Perhaps there is a technical solution that can be a happy medium?

The "fix" to incorrect configurations is to manually set up the affected objects - an exercise the developer will have to take anyway if autoresolve would be disabled. In this case, it would be beneficial to have autoresolve enabled, and just manually fix the affected incorrect configurations. This will avoid a lot MORE boilerplate on the objects that DO resolve correctly.

Another issue that has been raised was the difficulty in debugging. The true fault with this lies not in the autoresolve system but in its error reporting. It shouldn't be to hard to parse the backtrace and report the TRUE path:file where the error was triggered. This will make tracking down the location much simpler, and will beneficial (necessary?) also for if autoresolve were defaulted to disabled and has been enabled by a developer.

What other issues have you been experiencing with autoresolve?

Moshe

Brandon Savage

unread,
Dec 8, 2014, 6:32:24 AM12/8/14
to aur...@googlegroups.com
Imagine that you're configuring a template with an HtmlHelper. You tell the view template to instantiate My\Html\View\Helper, and you configure all of the services in a separate configuration file, for clarity.

Except you forget to include the file in which the services are configured.

Aura.Di, with autoresolve turned on, will use reflection to identify the My\Html\View\Helper class, and load it. It will also analyze the dependencies of that class, if there are any, and configure those as well. It *won't* tell you that anything is wrong, or that it did the auto-resolution for you.

What happens? When you go to use the services for the first time, you get an unexpected error because the services don't exist. And you get no indication of the fact that the problem was caused by Aura.Di.

When Paul says that autoresolution was his biggest mistake ever, I don't think he's kidding.

Brandon

--

Moshe Brevda

unread,
Dec 8, 2014, 7:22:37 AM12/8/14
to aur...@googlegroups.com
I think you're saying that in certain situations the actions of Di is unpredictable?

Couldn't you just disable autoresolve in those instances?

It would seem that in the example you described Di is acting exactly as it should (i.e. being smart about things, even if overly so). Furthermore, in that example, even without autoresolve you would have similarly eyebrow-rasing behaviour had you set up the configs manually and forgotten to include them. The issue isn't Di specific.

Finally, who includes filed? I havent included a single file since I started using composer :)

You received this message because you are subscribed to a topic in the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/auraphp/DEu2mDmJ_dg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to auraphp+u...@googlegroups.com.

Brandon Savage

unread,
Dec 8, 2014, 7:31:12 AM12/8/14
to aur...@googlegroups.com
The actions of Di are unpredictable; until the can be made predictable, it should be turned off for everybody.

As for whether or not the issue is Di specific, it is: assuming that the object I'm including has a __construct() element of any kind, if I fail to include the configuration in some way, Di will fail with a reflection error (with autoresolve turned off). This immediately tells me that I forgot to include something and points the direction to where the problem lies. Instead, with autoresolve turned on, the autoresolve resolves the dependencies, and doesn't tell me that it did so.

As for your condescension (which is unnecessary), if you don't require or include anything, how do you load the Composer autoloader? I'm willing to place a small wager that you also, at some point, include/require a configuration file.

Brandon

Moshe Brevda

unread,
Dec 8, 2014, 7:41:39 AM12/8/14
to aur...@googlegroups.com
Good point, that is the only require - although thats "built in" by Aura (when basing a project of WebProject or the like). Perhaps you misunderstood my intentions, I was just trying to lighten the mood. Obviously different projects are going to be set up differently  - and that's ok.

Back on topic, Ill just summarize with the following: Auto resolve works great as it is today, is fully predictable (i.e. if you screw up it will do weird things, if your fully psr4 compliant, fully autoloaded you have a lot of your work done for you), and is a big step forward for Di. That being said, I would focus energy on making it even smarter - by trying to add some verbosity/error handling so that it performs more reliably in corner cases/cases of error - and not try to move it backwards by hiding one of its most promising features.

Brandon Savage

unread,
Dec 11, 2014, 6:20:27 PM12/11/14
to aur...@googlegroups.com
Another solution to this would be to allow Aura.Di to resolve the dependencies only of those objects it was taught how to create. 

For example, if my controller accepts a request object, and Aura.Di has been taught how to create that object, no problem. If the object is unknown, it could throw an exception. 

This is similar to how other auto resolving DI containers operates. 

Sent from my iPhone

Hari K T

unread,
Dec 11, 2014, 9:50:18 PM12/11/14
to aur...@googlegroups.com
I wrote a blog post a few days back, pushed it yesterday only http://harikt.com/blog/2014/12/06/speedup-configuration-aura-v2/ .

May be anyone will be interested .

Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

Paul M. Jones

unread,
Mar 26, 2015, 4:05:27 PM3/26/15
to aur...@googlegroups.com
Hi all,

Coming back to wrap up this thread.

> On Dec 1, 2014, at 17:15, Brandon Savage <bra...@brandonsavage.net> wrote:
>
> Hello all,
>
> In v2 of Aura.Di, we introduced an auto-resolution feature that would create objects if the DI container knew how. This creates a number of problems where the DI container determines it can create an object, but does so with incorrect configurations. Currently, by default, Aura.Di turns autoresolution on by default. It's my recommendation that this feature be turned OFF by default.

It sucks, but doing so would be a BC break. A change for this will have to wait for the 3.x version. To soothe the folks who like auto-resolution, it's possible that 3.x may have two implementations: an auto-enabled one, and a manual-only one.

I say again that enabling auto-resolution in the DI container, especially by default, was the biggest mistake I ever made in that package, perhaps in the entire Aura project.



--
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



Reply all
Reply to author
Forward
0 new messages