Sorry, my bad, Pr stands for “Protocol example”
ityonemo
Qqwy
TypeCheck Core Team
Correct. The expectation in this particular case is that the arrays are used in algorithms whose performance is governed by the number of elements rather than by the number of arrays (i.e. the number of Array.empty/1-calls being much lower than the other operations).
If this does happen to be slow, someone could perform this wrapping manually to create ‘default options’ which are then explicitly passed, as alternative to ETS.
@ityonemo are you sure that is okay? I always thought that a protocol did not like it if you add functions whose first parameter is not the thing implementing the protocol.
0
ityonemo
It’s fine. A defimpl is just a module, it can have whatever functions you want. It’s the defprotocol that is special. And note that Pr is not a defimpl, it’s just module that “inherits” the P “interface” contract.
If you only want those extra functions in the “outer” module, then you can make it an optional callback, do the impl modules won’t emit comptime warnings.
0
eksperimental
First of all I would like to mention that defining callbacks with the @callback directive is discouraged.
While it can still be used, ExDoc will not list these callbacks in the protocol documentation.
See this issue for reference.
https://github.com/elixir-lang/ex_doc/issues/1320
The approach that I ended up taking was to define a submodule called Behaviour, where you can end up placing all your @callbacks. There is a caveat though, that the functions that define functions/macros are not available, this is due to the way protocol is implementing disabling these functions in the parent module. One way to solve this is to create a module outside the protocol definition (defmodule MyProtocol.Behaviour).
But for clarity I preferred to keep it as a submodule.
You can see the implementaiton of this here:
https://github.com/eksperimental/buildable/blob/cf6be3dee76bf6dab39517b58bfa5de441b05427/lib/buildable.ex#L1
Please let me know what you think about this approach
2
Qqwy
TypeCheck Core Team
It seems to me like we are treading in unexplored waters, and am eager to learn what people of the Elixir core have to say about this situation.
2
eksperimental
The one conflict that I can foresee is that if somebody defined a %Behaviour{} struct, it will collide with the submodule we created, given it implements the protocol.
0
Qqwy
TypeCheck Core Team
eksperimental
Yes. So if you do defimpl Buildable, for: Behaviour it will create Buildable.Behaviour.
Which is very unlikely somebody will define a struct with the name of a module that exists in Elixir core and is already deprecated,
But I am just saying it is something to keep in mind when creating submodules under the protocol namespace
1