Thanks for the idea, I'm not sure if that would help improve much Adam,
I've played a bit and it seems it would be just slightly worse:
```shell
lib/usage.ex
└── lib/impl_selector.ex
├── lib/impl_a.ex
│ └── lib/impl_behaviour.ex (compile)
└── lib/impl_b.ex
└── lib/impl_behaviour.ex (compile)
```
```shell
lib/usage.ex
└── lib/proto.ex
└── lib/proto_impl.ex
├── lib/impl_a.ex
│ └── lib/impl_behaviour.ex (compile)
├── lib/impl_b.ex
│ └── lib/impl_behaviour.ex (compile)
└── lib/proto.ex (compile)
```
In the end, from what I get, if the dependency chain is clean of compile
deps in between (ideally `(compile)` should just be in the leaves, as in
the tree above), this shouldn't increase recompilations, I'll try to attack
all of these in our codebase, if I manage to get there, then these runtime
deps shouldn't be a problem 👍
On Friday, October 9, 2020 at 10:55:09 PM UTC+2 [email protected] wrote:
> Knowing nothing about your app, and therefore nothing about whether it’s a
> good idea or not, I’m curious if the dependancies change if you use
> protocols instead of the ImplSelector?
>
> On 9 Oct 2020, at 21:41, Victor Rodrigues <[email protected]> wrote:
>
> 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
>
> <https://groups.google.com/d/msgid/elixir-lang-core/d4c1e0c0-839b-4d87-8f5c-597cf17110d1n%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/c3fbb443-c49b-40a2-a854-1d4e61cb6615n%40googlegroups.com.
