Support conflict resolution in protocol consolidation

[kelostrada]

hey, is there somewhere any discussion regarding this? How will it work? Do you plan on making possible to use two different implementations of the same protocol in two different dependencies, or resolution of conflicts means you will be able to chose which implementation to use ?

[josevalim]

Do you plan on making possible to use two different implementations of the same protocol in two different dependencies, or resolution of conflicts means you will be able to chose which implementation to use ?

The latter. You cannot chose per dependency.

[josevalim]

Unfortunately we cannot effectively tackle this, instead it should be done as part of the release building process, as it is the one that will effectively detect duplicates and could present the user to choose which option they want.

[josevalim]

@ericmj suggested us to use the consolidation directory for solving conflicts. It will likely work.

[michalmuskala]

How would this work exactly? How would I specify which implementation to use, and how would they be differentiated since both have the exact same module name.

[josevalim]

Since we already overlay protocols in the consolidation path, we will do the same with implementations, picking one of them based on the application name. So you will be able to say:

consolidate: %{Foo.Bar => :my_app}

Or something of sorts.

[michalmuskala]

Makes sense, I had something similar in mind.

[josevalim]

After further consideration, we are not going to include this feature on v1.4. The biggest concern is that we don't have enough scenarios or use cases where this feature is necessary and allowing conflicts to be resolved will increase the cases where implementations are overridden on purpose while properly addressing it all on a single implementation would be preferable.

This may also mean we should finally introduce something like Clojure's reify. Therefore, we would like to hear more use cases and scenarios on how to properly solve this problem.

[asafigan]

I'm new to Elixir, so I don't know much about the language and how it is used. After learning about the import syntax, I instantly know that this would be an issue in the language and started to search for solutions to it. I just want to mention two solutions from other languages. One is EcmaScripts import syntax, which basically requires two inputs: the file path of the module, and what it will be called in the current file scope. This is super simple and intuitive to me, but EcmaScript is completely different than Elixir. Also, Jonathan Blow has a video that touches on this issue with compiled languages (https://youtu.be/iUYZNbUKVAc). He has a very unique solution to the problem in his language. I think the similarity in these two solutions is that you as the programmer have complete control over how you reference your dependences, rather than having your dependences dictate how your reference them.

[asafigan]

BTW, just wanted to say that I have like the language so far so keep up the good work.

[asafigan]

Just wanted to give a useful time stamps on that video. 16:00 is the initial discussion. 27:50 is the part that starts talking about this problem in particular. At 33:20, he starts going into his solution.

[josevalim]

@asafigan the import issue is a separate issue from the one being discussed here. The import issue also has a clear solution in Elixir's case, in case of conflicts we warn and you can always use fully qualified names or aliases to solve the ambiguity.

[asafigan]

ok sorry for misunderstanding the problem

[josevalim]

Closing this due to the lack of activity.