Does anybody else feel this way about @spec (visually overpowering)?

Anybody here feel this way (or have better syntax highlighting)?

It feels overwhelming/noisy.

4 Likes

I don’t really agree, but why not just change your theme to make up for it? It’s not very likely to change based on the idea of it being too visually distinctive.

4 Likes

but why not just change your theme to make up for it

That’s not necessarily a simple thing to do. That’s why I’m asking around.

1 Like

What editor and theme are you using? I don’t know of any modern editor/IDE that doesn’t have (comparatively) easy theme management.

I think he means, changing the spec thing without changing everything else.

1 Like

Yeah, I’ve used a few editors and themes and none of them seem to do what I want. I want to see if I’m not alone. (currently using vscode)

I think @spec should look closer in appearance to documentation than code.

In that case I suppose it’d be an issue of having the @spec part be parsed as documentation in, for example, the ElixirLS extension in VS Code. I’m not entirely sure which part does the actual parsing of the text, but presumably it’s in a public repo.

Edit:

There you can see the syntax highlighting part for docs. Adding @spec as a pattern there should probably make it so that it’s highlighted as documentation. Fork the repo, make the change, run your own version of the extension.

If it’s not exactly there, it’ll likely be as easy somewhere else in that file.

I don’t agree it’s visually overpowering.

@spec is a part of code not a part of documentation. It defines really important thing, types for function parameters and type of function return value, which helps in code readibility and code understanding.

Side note:

In PHP types should be written in function clause:

public function getIntegrationProvider(int $provider_id): IntegrationProvider
{
}
2 Likes

This is pretty secondary to his own taste. If he wants to run an extension that treats it visually as documentation, that’s really his prerogative. I think the bigger point here is that it’s probably better to look to your tooling rather than try to make changes on a compiler/community level.

2 Likes

Yep. You are rigth.

1 Like

And keep up with bug fixes, patches and releases. Which is why I said it’s not necessarily a simple thing to do. :frowning:

I’m not trying to change the language or compiler. I’m trying to see if there are other people who feel the same way I do and if they have found or come up with any good solutions.

1 Like

It gives you information, for readability and understanding. It does not enforce types in the function, and as far as I know it does not change anything about the function when compiled and is not part of the function execution. That is my argument for considering it closer to documentation than code.

That’s only if you want to enforce the argument types.

1 Like

@ryanwinchester This seam like a really good case for a PR there would make the styling more flexible
it could be nice to be able to define it in the settings.

the only other option here is just not to use specs.

1 Like

Well, considering you’re running VS Code, the extension you (should) use actually does continuous checking of type specs by way of dialyzer without any additional configuration, so with that in mind it’s not quite as deferred as you make it seem. Normally, I’d agree with your sentiment, but not with this specific extension.

1 Like

They are annotations for you to read, and that tools can also use to help you. There are tools (and IDEs) that also use PHP docblocks to do the same thing.

That feeling may simply be informed by your previous personal experience.

For example someone who has worked primarily with dynamically typed languages may not attach a lot of importance to explicitly declared types.

It does not enforce types in the function, and as far as I know it does not change anything about the function when compiled and is not part of the function execution.

The specs are an input for success typing so they actually go beyond “mere” documentation. But viewing syntax highlighted code in an editor is entirely for the benefit of the human reader anyway.

I for one consider the intended types to be important and useful information regardless whether the actual code requires them or not - so I appreciate the additional emphasis even against the “real code” (the whole “thinking in types” thing).

But obviously that is a YMMV issue that can to be controlled via configuration of the viewing/editing tools.

1 Like

Yep. It’s a pity it’s not enforcing types in compilation time.

But in some way it can enforce some kind of type cheks when you are using dialyzer - as some kind of additional step before compilation.

You know that you can move it closer to documentation by defining just empty function clause and place your @spec there with documentation anywhere in your file. It will not pollute your function definition with implementation.


# you got here just plain function
def some_function(some_arg) do
  #some implementation
end


#Many code here


@doc """
Quite good docs.
"""
@spec some_function(SomeType.t()) :: SomeOtherType.t()
def some_function(some_arg)

But that way you lost some code readability and it’s harder to understand what is going on in some_function() implementation. :slight_smile:

1 Like

… and the one you use happens to be one of the tools that does this by default, which means that this feeling you have of them not being important while developing, other than informing the programmer, is practically speaking misguided.

I’m still wondering exactly what it is that you hope to do about this, considering you’re basically shooting down any suggestion that you’ve been given. You have the tools to change this for yourself in order to make the type specs less pronounced. What’s this discussion actually about?

2 Likes

Uhh, why would you not want to? Types put into comments is as good as no types at all as far as the compiler is concerned… o.O

Do note, dialyzer is part of and comes with the BEAM/OTP.

Add it as a git pre-commit hook or in your CI or as part of your compilation command itself. :wink:

I would so very much love this instead:

def some_function(some_arg :: SomeType.t()) :: SomeOtherType.t() do
  ...
end

Then have each head be properly combined and all finally as a BEAM spec. :slight_smile:

6 Likes

:slight_smile: Yeah I got it in script additionally with credo --strict

It reminds me statically typed languages with “looong” function heads. :wink:

Personally I like more the way with annotation like in Haskell or Elixir, why?, because firstly I write @spec so I need only to name function and define its types (how it works - inputs and output). After that I have to think up the name for arguments. I got some separation from named things and types.

2 Likes