Also, I forgot to mention, it was @icecreamcohen on discord who had the
idea that redefining alias may work (although they didn't really condone
it), don't want to take credit for anyone elses ideas though.
On Monday, May 9, 2022 at 1:53:50 PM UTC-4 Zach Daniel wrote:
> This is something coming from a compile time optimization that Ash
> Framework does.
>
> In an Ash resource there is something called a change its basically like a
> plug but it operates on an Ash.Changeset
>
> So you might see something like this:
> ```
> # in the resource
> actions do
> create :create_with_employee do
> change MyApp.CreateEmployee
> end
> end
> # the change module
> defmodule MyApp.CreateEmployee do
> use Ash.Resource.Change
>
> def change(changeset, _opts, _context) do
> Ash.Changeset.after_action(changeset, fn _changeset, result ->
> MyApp.Employee.create!(result.stuff, ...)
> end)
> end
> end
>
> Now, the change itself, when it comes to the resource, is simple static
> configuration. It cannot affect the compilation of the resource nor should
> any thing doing metaprogramming at compile time leverage the internals of
> that change
>
> Something that changes do often is refer to other related resources, like
> in this example case. So we drastically increase the surface area for
> transitive compile time dependencies
>
> Because a runtime dependency in one link becomes a compile time dependency
> when chained down the road. I.e I depend on the source resource, call it
> Post at compile time, and Post depends on Employee now at runtime, so I now
> depend on Employee at compile time.
>
> So to help people with their compile times, I've added some
> metaprogramming magic that does the following (only in very specific places
> for specific options) Macro.expand(node, %{env | lexical_tracker: nil}) and
> it works, no more unnecessary dependency. however, if you do this:
> ```
> alias MyApp.CreateEmployee
> create :name do
> change CreateEmployee
> end
> ```
> it yells at you for not using the alias, because I just disabled the thing
> that would inform the compiler that the alias was used
>
> I don't necessarily want to add back in those unnecessary compile time
> increases, so I'm looking for a way to detect that an alias had been used
> in these cases, and produce a compiler warning if you didn't add warn:
> false to the alias, that way you don't get a confusing "alias not used"
> error, you get (well, I guess you get both) an explanation of why the alias
> wasn't used and instructions to add warn: false to fix it.
>
>
> The options I have so far:
>
> 1. redefine `alias` and default to `warn: false`
> 2. redefine `alias` and track which ones have `warn: false` and print a
> warning if its used in one of these instances, so they can add it
> 3. if I detect that an alias is used, raise an error at compile time and
> say that aliases aren't supported here
> 4. get something in elixir core that allows explicit control to add
> something to an explicit list of "used aliases"
>
> Looking at the code for the lexical_tracker, it could be as simple as
> tracking a separate list of explicitly provided modules, or it could be a
> different mode of reference, i.e `:compile` `:runtime` or `:ignore`, that
> kind of thing.
>
> Also, if there is another way to accomplish the goal here I'm open to
> suggestions.
>
> Thanks!
>
--
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/f8e4ed44-f3a8-41cc-b82c-f6175ea461fdn%40googlegroups.com.
