I don’t like the way Elixir work inside current module, better has an auto alias like alias __MODULE__ than must add it manually (I usually add this to my module) or type __MODULE__.
For me, when look to __MODULE__ I need a little of bit to think about what is the current module.
Do you mean you type this literally, or like alias __MODULE__.Foo? If the former, why would you do this? Seems like any confusion you’re having may be caused by over-aliasing, though hard to tell.
While no solution is perfect, I find that far more often than not I know what module I’m in. When unsure, most modern editors have features like hovering and, even better, scroll context which will pin the defmodule line to the top as you scroll. Barring any of that, usually a quick glance at the filename does the trick.
For me, I usually code like:
defmodule MyApp.Foo.Bar do
defstruct
[
:task,
:opts
]
alias __MODULE__
def do_task(%Bar{} = task) do
# do somethings
end
end
This way help me easy to read & maintain than using __MODULE__ in everywhere.
Oh… ya I mean, different stokes, I guess. This would be crazy confusing to anyone coming in blind to this. I would first assume that Bar has been aliased in from another module but since it’s not explicitly present in the alias list, it then looks like a top level module. You have to “be in on it” to get it and even then, you can’t always be 100% alias __MODULE__ is present. This is terrible for scanning. But again, to each their own!
Yes, that is just a personal feeling of mine. Read a meaning word help me easy to understand.
I agree with you there. For me __MODULE__ now read like this in OOP languages. It automatically forces me to think “module I am currently in”. It is a little bit verbose, but at the same time it makes it distinct enough.
So I 100% prefer __MODULE__ over alias __MODULE__ (it also help with refactoring).
Do wonder why. Modules are usually referenced in other files, so how come the file the module is defined in is so special it ‘adds’ work during refactoring?
The only extra info of __MODULE__ is “struct can be found in this module too”, at the expense of a braincycle “what module am I in?” and not being able to ‘grep’ all occurrences of struct.
Most of @sodapopcan his arguments are only valid for those not into the conventions of adding the alias and then using it consistently.
Ps. I do use the module notation a lot. Still challenging assumptions and statements.
It’s not like it’s a slam dunk, but it’s a nice little perk when renaming, reducing noise.
I honestly don’t even think I’ve grepped for a stuct, though if you are aliasing how are you going to reliably grep for it? Of course you can do wildcards, but that will return matches of possible other aliases with the same name in different files.
Otherwise, and this is getting very bike-sheddy, pretty much all the places I use __MODULE__ has a variable or spec right there with the name of the module I’m in but ya, I won’t repeat my arguments over but I will say again: to each their own! The only thing I think is super janky (and will be adding to my grumpy credo rules of all the confusing things I see people do with this language) is alias __MODULE__. Just spell the dang thing out!
Though I am interested:
Are you saying that you add aliases and then sometimes don’t use them or you just generally don’t alias at all? If the latter, I’m generally all for that! I used to not alias at all though recently started when someone pointed out that it’s a great way to create a natural list of depenencies but part of me is thinking of going back. (and if this is the case then your grepping argument makes sense).
EDIT: Also, my argument (for me) still stands that if I see a module reference, my brain thinks “remote,” which is true with or without aliases, so no saved brain cycles for this guy!
Ok, I think I think I’ve sufficiently painted my side of the shed 