# @behaviour, @callback and @spec

**URL:** <https://forum.elixirforum.com/t/behaviour-callback-and-spec/20463>\
**Category:** Questions\
**Tags:** behaviours, dialyzer\
**Created:** [February 26, 2019, 11:22pm UTC](https://forum.elixirforum.com/t/behaviour-callback-and-spec/20463 "2019-02-26T23:22:07Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![paseg](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/paseg/32/7825_2.png) [@paseg](https://forum.elixirforum.com/u/paseg)\
**Post date:** [February 27, 2019, 7:58am UTC](https://forum.elixirforum.com/t/behaviour-callback-and-spec/20463/10 "2019-02-27T07:58:03Z")

</div>

Hi

Wow, thanks for all comments! Did not know that this would stir up this many opinions. 🙂

A see your point @asummers, but since this is not a public library (“only” used within our company), I prefer that the implementers spend the extra time to go into the definition of the behaviour rather than using multiple specs that will effect the maintenance in the long run.

I also found that the `@spec` may state less than the actual `@callback` without Dialyzer telling me, witch gives me another argument not to use the @specs…

Example given:

```elixir
defmodule Register.DocEvents do
  @callback initialize(soure :: binary() | atom()) :: :ok | {:error, String.t()}
end

```

```elixir
defmodule Register do
  @behaviour Register.DocEvents

  @impl Register.DocEvents
  @spec initialize(atom()) :: :ok
  def initialize(source) do
    ...
  end
end

```

Dialyzer signals this is ok, and I guess it is since the actual implementation fits within the original specification. In this case, the `@spec` makes sense since this implementation is not the same as the `@callback` stated, but if they are expected to be the same then adding an extra `@spec` just creates more maintenance burden.

---

_[View the full topic](https://forum.elixirforum.com/t/behaviour-callback-and-spec/20463)._