-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle de-duping of Modules (the "diamond" problem) #31
Comments
From dhanji on April 17, 2007 04:44:51 how is this any different from A installing D twice? Isnt that supposed to be disallowed? Or would the contract change to re-registering An unwitting user would think he has "overridden" D-t1 by D-t2. I think Im missing something here... |
From kevinb9n on April 19, 2007 11:26:42 A installing D twice should be harmless. It's not essential for it to be harmless, I believe it's going to be too burdensome on someone with a large and complex Luckily I think the solution to this is simple; we'll just keep a hash set of Modules I think this is the best we can do since we never know when someone might have a |
From kevinb9n on April 20, 2007 12:04:40 Well, I have this working now. I'm not sure if it's awesome, though. You, of |
From kevinb9n on April 29, 2007 11:39:35 Fixed r320 . Status: Fixed |
From kevinb9n on February 26, 2007 22:17:14
if module A installs B and C and B and C both install D, you'll get errors
and you won't be able to create the container. We should be able to detect
this situation somehow and handle it correctly.
Original issue: http://code.google.com/p/google-guice/issues/detail?id=31
The text was updated successfully, but these errors were encountered: