Skip to content
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

Closed
gissuebot opened this issue Jul 7, 2014 · 4 comments
Closed

Handle de-duping of Modules (the "diamond" problem) #31

gissuebot opened this issue Jul 7, 2014 · 4 comments

Comments

@gissuebot
Copy link

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

@gissuebot
Copy link
Author

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
registered modules is silently ignored? If so, what is the strategy for comparing
module D at time t1 vs t2?

An unwitting user would think he has "overridden" D-t1 by D-t2.

I think Im missing something here...

@gissuebot
Copy link
Author

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,
but it would become harmless if we fix this issue, and I think making it harmless
is... uhh, harmless.

I believe it's going to be too burdensome on someone with a large and complex
codebase like we have in my company to keep his/her module inclusion graph as a
strict hierarchy/tree.  I think it would cause a lot of ugliness to happen to work
around the restriction.

Luckily I think the solution to this is simple; we'll just keep a hash set of Modules
we've installed.  Now, if a user in one place installs "new MyModule()" and in
another place also installs "new MyModule()", it will still fail.  But at least now
we have a simple fix -- we advise the user to add an equals() method to the module
(or, I suppose, share the instance somehow).

I think this is the best we can do since we never know when someone might have a
module class which is actually parameterized with some constructor args that control
what stuff gets bound.

@gissuebot
Copy link
Author

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
course, have to override both equals() and hashCode().  So I dunno if anyone else has
any better ideas... if not, I'll submit what I've got.

@gissuebot
Copy link
Author

From kevinb9n on April 29, 2007 11:39:35

Fixed r320 .

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant