Thanks, now I get it! 👍

It seems this kind of function might not be the best strategy 
dependency-wise to resolve behaviours at runtime, since the consumer of the 
`ImplSelector.resolve/1` function ends up with all the cruft from all 
implementations, transitively.

Thinking now perhaps processes would be the only way when we’d really want 
to isolate these calls from propagating impl deps.

On Friday, October 9, 2020 at 10:09:50 PM UTC+2 José Valim wrote:

> Unfortunately we cannot remove those, precisely because they may be 
> invoked when passed to another function.
>
> On Fri, Oct 9, 2020 at 21:44 Victor Rodrigues <[email protected]> wrote:
>
>> Hi, I’m working towards reducing the recompilation dependencies on a 
>> project with hundreds of modules.
>>
>> Digging through this, I’ve stumbled into something that I didn’t expect:
>>
>> When a function returns modules as values, that creates a runtime 
>> dependency to these modules.
>>
>> Taking the example below:
>>
>> ```elixir
>> defmodule ImplSelector do
>>   def resolve(impl_type) do
>>     case impl_type do
>>       :foo ->
>>         ImplA
>>
>>       :bar ->
>>         ImplB
>>
>>       :omg ->
>>         :"Elixir.ImplC"
>>
>>       :wut ->
>>         NonExistingMod
>>     end
>>   end
>> end
>> ```
>>
>> ```shell
>> ➜ mix xref graph --source lib/impl_selector.ex
>> lib/impl_selector.ex
>> ├── lib/impl_a.ex
>> │   └── lib/impl_behaviour.ex (compile)
>> └── lib/impl_b.ex
>>     └── lib/impl_behaviour.ex (compile)
>> ```
>>
>> It creates runtime deps from ImplSelector to Impls A and B. C is left 
>> because I’ve used :”Elixir.ImplC”, and as a non existing module doesn’t 
>> raise any warnings (just an atom after all right), I wonder if we could 
>> remove these dependencies too, or if it’s really desired.
>>
>> We rely a lot on behaviours, and figuring these from instance 
>> configurations. I think that would have a good impact on the dependency 
>> graph overall, if it’s something that could go.
>>
>> Thanks!
>>
>> ----
>>
>> A bit off-topic, but wanted to share that when I started this saga this 
>> week, Elixir 1.11 only reduced ~10% the modules on recompilation, but now, 
>> as I’ve fixed a few important dependencies (still a lot to go), I can see 
>> already ~50% less modules recompiling in 1.11 as compared with same code in 
>> 1.10.4! 🌈
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/216ce42b-9fe0-4e28-a5b9-acdde5414c41n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/216ce42b-9fe0-4e28-a5b9-acdde5414c41n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/d4c1e0c0-839b-4d87-8f5c-597cf17110d1n%40googlegroups.com.

Reply via email to