Is this error overly-zealous?

[pragdave]

Given this behaviour:

defmodule Bunyan.Shared.WritableServer do

alias Bunyan.Shared.LogMsg

@callback handle_cast({ :log_message, msg :: LogMsg.t}, options :: any()) ::

{:noreply, new_state}

| {:noreply, new_state, timeout() | :hibernate}

| {:stop, reason :: term(), new_state} when new_state: term()

end

and this module

defmodule Bunyan.Writer.Device.Server do

use GenServer

@behaviour Bunyan.Shared.WritableServer

. . .

I get the following warning:

warning: conflicting behaviours found. function handle_cast/2 is required by GenServer and Bunyan.Shared.WritableServer (in module Bunyan.Writer.Device.Server)

lib/bunyan_writer_device/server.ex:1

But the @spec for handle_cast in WriteableServer (my module) is a proper subset of the @spec for handle_cast in GenServer, so there isn't an actual conflict: my spec simply says that among all the handle casts there must be at least one with that form.

Would this be too difficult to detect?

Dave

[José Valim]

Unfortunately it would, as we would need to be able to fully resolve types. {:ok, String.t} is the same as {:ok, binary()}. {:ok, foo()} is a subset of both {:ok, foo() | bar()} and {:ok, foo()} | {:ok, bar()}. %{integer() => integer()} is a subset of %{number() => number()} and %{integer() => integer(), float => float()} and so on.

There is also the question of, even if we can detect that you have subset, what does it mean? Does it mean you accept only the subset? If so, should we just ignore the other entries? Or do you want to accept the superset?

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6d0ba9d2-e23c-4325-b37d-d678fc5a5dd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pragdave]

There is also the question of, even if we can detect that you have subset, what does it mean? Does it mean you accept only the subset? If so, should we just ignore the other entries? Or do you want to accept the superset?

I definitely see the difficulty. Maybe some PhD candidate would want to write a full type engine for you.

As the the meaning, I think the interpretation of 

 @callback ..spec..

is that the implementer must include a function that honors «spec».

So given

@callback hello(atom()):: any()

and

@callback hello(:world):: any()

the following module would satisfy either individually, and as a result both together.

defmodule A do


  def hello(:world), ...
  def hello(:josé)
  def hello(a)


end

[José Valim]

the following module would satisfy either individually, and as a result both together.

So the subset callback exists only for documentation purposes right? Because anything else will be matched against the superset, correct?

[pragdave]

On Friday, June 22, 2018 at 10:19:32 AM UTC-5, José Valim wrote:

the following module would satisfy either individually, and as a result both together.

So the subset callback exists only for documentation purposes right? Because anything else will be matched against the superset, correct?

In the case where the consuming module uses both, then yes. But the consuming module could use just one... 

[José Valim]

I see. Unfortunately I can suggest anything better than do not @behaviour the subset behavior when you are also using a GenServer. Sorry.

--