I could not agree more. @specs are really quite ugly.
I suggest putting a blank line between your @specs and function heads.
net
2
ryanwinchester
I think you are missing my point. I never said they were not important. They are there to provide info, to you or to tools. That’s important.
1
gon782
Yes, I think that’s a concise summary. Hence the question in my previous post: What’s the goal here? I think making your own modification to ElixirLS is trivial and the only upkeep you’d need to do personally is to git pull their changes whenever you feel like it. Considering the minor changes you’d make for this conflicts are extremely unlikely. At “worst”, you’d make a PR to make the syntax highlighting of @spec configurable.
1
ryanwinchester
Because type-hinting in PHP actually kind of sucks for a really long time (although they are fixing it). If you want to pass in an iterable object, or an array you couldn’t enforce a type if you want the users of your library to be able to use either, even though either are iterable. You can typehint for array or ArrayAccess but not both. You could type hint for an iterable object or an array, but not both. So, there are cases where enforcing types in PHP can kind of suck for your users. A docblock in PHP is similar to a @spec in elixir. You can have static analysis, IDEs can provider autocomplete and hints, etc. but they aren’t used by compiler or execution.
0
OvermindDL1
ryanwinchester
merlin
@spec some_function(SomeType.t()) :: SomeOtherType.t()
def some_function(some_arg)
This feels so heavy and much harder to read. Strong/static typing is the feature I really miss in Elixir. Esp. from a security standpoint I really like to know what types of data get in/get out.
+1, this is much better, concise and readable
btw does anybody know where I could find Elixir grammar/formal spec if it exists ?
1
peerreynders
Again this relates entirely to what you are familiar with.
I used to feel the same way until I realized that declaring names and types in the same definition forced multi-line signatures much faster. Some might argue that keeping names and types separate is actually more concise - similar to how header and row information in a table interact, The spec focuses on typing while the function header focuses on naming - sacrificing easy parameter name/type correlation for focus.
The first approach declares a function type while the second approach types the parameters and the return value - producing a function type as a side effect. (Sometimes “preferences” can get in the way - accept whats there and move on).
3
merlin
Yes, indeed. As is your post 
If you think that this:
@spec some_function(SomeType.t()) :: SomeOtherType.t()
def some_function(some_arg)
is easier to read, more concise and less error-prone than:
def some_function(some_arg :: SomeType.t()) :: SomeOtherType.t() do
end
So be it. Let’s agree to disagree.
What if you had 40 000 functions ? Would you write 40 000 separate type defs, including misc. pattern matching function prototypes ? Aren’t you afraid your code base might quickly become bloated ?
1