So all we we do is hold onto the module, and then at runtime we go through the list of modules that we should call and call a specific function on them. Requiring a runtime dependency for that is causing really slow compile times because of transitive dependencies. Maybe there is some consequence I don't see, but I removed the runtime dependencies by disabling the lexical tracker when expanding the alias, and its been that way for months w/o anyone reporting any issues with that implementation. Aside from having to use `warn: false` if they use aliases.
To me, its the same as if they gave us, instead of a module, an `atom` that referred to application configuration, i.e the adapter pattern. That would work without a runtime dependency, so why couldn't this? On Sun, Sep 11, 2022 at 2:56 PM, José Valim < jose.va...@dashbit.co > wrote: > > Sorry, correction: If, at any moment, you call any function from that > module at runtime, you must not remove the *runtime* time dependency. > > > On Sun, Sep 11, 2022 at 8:55 PM José Valim < jose. valim@ dashbit. co ( > jose.va...@dashbit.co ) > wrote: > > >> Why do you want to remove the runtime dependency when, per your >> description: >> >> >> > In Ash Framework, we have declarative ways to construct *runtime* behavior >> using behaviors. >> >> >> Emphasis mine. If, at any moment, you call any function from that module >> at runtime, you must not remove the compile time dependency. >> >> >> On Sun, Sep 11, 2022 at 8:52 PM Zach Daniel < zachary. s. daniel@ gmail. com >> ( zachary.s.dan...@gmail.com ) > wrote: >> >> >>> `expand_literal` removes the compile time dependency, but leaves a runtime >>> dependency when used inside of a module. >>> >>> What I'm trying to do is remove both the compile time dependency *and* the >>> runtime dependency, without requiring the use of `warn: false` on aliases. >>> >>> >>> >>> >>> >>> >>> On Sunday, September 11, 2022 at 2:31:42 PM UTC-4 José Valim wrote: >>> >>> >>>> Sorry, I don't understand the proposal. You mentioned expand_literal, >>>> which already removes the compile-time dependency but keeps the remaining >>>> functionality such as warnings. Can you please expand? >>>> >>>> >>>> >>>> On Sun, Sep 11, 2022 at 7:57 PM Zach Daniel < zachary.... @ gmail. com > >>>> wrote: >>>> >>>> >>>>> For clarity, the dependency I'm talking about there is the dependency from >>>>> `MyApp.User` to `MyApp.User.Changes.HashPassword`. >>>>> On Sunday, September 11, 2022 at 1:55:51 PM UTC-4 Zach Daniel wrote: >>>>> >>>>> >>>>>> In Ash Framework, we have declarative ways to construct runtime behavior >>>>>> using behaviors. So an Ash resource might look like this: >>>>>> >>>>>> >>>>>> ```elixir >>>>>> defmodule MyApp.User do >>>>>> use Ash.Resource >>>>>> >>>>>> alias MyApp.User.Changes.HashPassword >>>>>> >>>>>> attributes do >>>>>> uuid_primary_key :id >>>>>> .... >>>>>> end >>>>>> >>>>>> actions do >>>>>> create :register do >>>>>> change HashPassword >>>>>> end >>>>>> end >>>>>> end >>>>>> ``` >>>>>> >>>>>> However, by default, this would incur a compile time dependency. This >>>>>> compile time dependency is unnecessary, as we won't call any functions on >>>>>> this module or use it in any way until runtime. >>>>>> >>>>>> That optimization is well and good, but due to transitive compile time >>>>>> dependencies, we see some interesting behavior. Something you'd often see >>>>>> in a change module is things like pattern matching on other resources, or >>>>>> the resource in question in function heads. Resources are meant to be >>>>>> introspectable at compile time, and so this runtime dependency on a >>>>>> change, with a compile time dependency on a resource, incurs a transitive >>>>>> compile time dependency. This problem multiplies over time, and causes >>>>>> users to have to do things solely to optimize compile times, like only >>>>>> use >>>>>> map pattern matches instead of struct pattern matches. >>>>>> >>>>>> So what we do is we actually disable the lexical tracker when accepting >>>>>> certain parts of the DSL. This prevents *any* dependency. Naturally, at >>>>>> compile time you are no longer safe to call a resource's change module as >>>>>> changes in that module won't cause recompiles, but that was never a thing >>>>>> you should have done in the first place so I'm not worried about that. >>>>>> >>>>>> This leads us to the primary issue: disabling the lexical tracker when >>>>>> expanding aliases also causes warnings about unused aliases, even though >>>>>> they *are* used. I believe I've brought this issue up before and we were >>>>>> hoping that the feature introduced in 1.14 for `defimpl` would help, but >>>>>> that only helps prevent compile time issues, which is something I had >>>>>> already solved for in the same way it was solved for 1.14. I've laid it >>>>>> all out to help clarify exactly *why* I need it so perhaps someone can >>>>>> point me in a better direction. >>>>>> >>>>>> >>>>>> >>>>>> The simplest thing that could help: >>>>>> >>>>>> A way to tell the lexical tracker that an alias has just been referenced >>>>>> without inducing any kind of compile or runtime dependency. The idea is >>>>>> to >>>>>> just prevent it from warning about the alias. >>>>>> >>>>>> I'm open to other solutions as well. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>> -- >>>>> 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 elixir-lang-co... @ googlegroups. com. >>>>> To view this discussion on the web visit https:/ / groups. google. com/ d/ >>>>> msgid/ elixir-lang-core/ >>>>> 54627973-7b74-47d7-9e35-4270621e6c91n%40googlegroups. >>>>> com ( >>>>> https://groups.google.com/d/msgid/elixir-lang-core/54627973-7b74-47d7-9e35-4270621e6c91n%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 elixir-lang-core+unsubscribe@ googlegroups. com ( >>> elixir-lang-core+unsubscr...@googlegroups.com ). >>> To view this discussion on the web visit https:/ / groups. google. com/ d/ >>> msgid/ elixir-lang-core/ >>> 22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups. >>> com ( >>> https://groups.google.com/d/msgid/elixir-lang-core/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%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 elixir-lang-core+unsubscribe@ googlegroups. com ( > elixir-lang-core+unsubscr...@googlegroups.com ). > To view this discussion on the web visit https:/ / groups. google. com/ d/ > msgid/ elixir-lang-core/ > CAGnRm4%2BVkL%2B1V7LTDVyzhCqcNWrmHFPoWx2Fp916Ur%2ByL%2BiVBA%40mail. > gmail. com ( > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BVkL%2B1V7LTDVyzhCqcNWrmHFPoWx2Fp916Ur%2ByL%2BiVBA%40mail.gmail.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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/l7xp6eut.444ff913-f528-4b88-805a-cac120cdb4d6%40we.are.superhuman.com.
