VeljkoMaksimovic
Multiple aliases in one line with as:
Is there a way to have multiple aliases, but to use as: acronym for one of them, something like this, but that actually works ![]()
alias Guard.Rbac.{Cache, RoleBindingIdentification, as: RBI}
Most Liked
NobbZ
Using rarely, yes. Removing? No!
We have a codebase with more than 600 modules at work.
There are several modules ending in Product, within Schema, Dataloader, and what not prefixes. We do not want to repeat the type in the module name itself, therefore we are happy to be able to use :as in an alias.
bmitc
I don’t understand what that’s trying to specify. In this case, one is able to guess, though.
For me personally, I enforce the Credo.Check.Readability.AliasAs and Credo.Check.Readability.MultiAlias Credo checks for alias, among others. So the alias ___.{___} syntax and alias ___, as: ___ are not allowed.
Mutli aliasing is really only useful in very specific scenarios. It makes copying module names harder (impossible rather), and it starts to look ugly and busy when you have a lot of modules that aren’t just under a single “namespace”. Simply typing out the shared “namespace” is really not difficult.
I personally feel that alias ___, as: ___ should be used extremely sparingly if not removed from the language. It’s use is usually an indication that the module it is asing is poorly named. And I have certainly seen it heavily abused where the module was essentially renamed with as.
For the proposed:
alias Guard.Repo.{
RbacUser,
UserGroupBinding,
RbacRole,
{OrgRoleToProjRoleMapping, as: Mapping}
RoleInheritance,
SubjectRoleBinding,
{RoleBindingIdentification, as: RBI}
Permission,
Scope
}
it requires a fair amount of tracing to understand. I would suggest renaming the longer modules. RoleBindingIdentification could be RoleBindingId or even just RBI if you documented it with @moduledoc and the abbreviation is clear in the context. OrgRoleToProjRoleMapping should probably just be renamed.
Eiji
What you show in best case could work as:
alias Guard.Rbac, as: RBI
alias Guard.Rbac.{Cache, RoleBindingIdentification}
That’s because opts are on same level as other aliases.
Alternatively Elixir could support this:
alias Guard.Rbac.{Cache, {RoleBindingIdentification, as: RBI}}
However this looks just ugly and I guess that’s why it would be not supported at all. If you have an interesting idea how to improve that then feel free to create a proposal, but so far I do not see either a use case nor how it could look good at all.
Also keep in mind that even if such ugly-looking feature would be supported then it would be still formatted into multiple lines, so it would look like:
alias ParentName.{
{ChildA, as: A},
ChildB,
{ChildC, as: C}
}
I believe that keeping aliases work as it’s now is best.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








