# Protocols vs interfaces

**URL:** <https://forum.elixirforum.com/t/protocols-vs-interfaces/46527>\
**Category:** Discussions\
**Tags:** metaprogramming, protocols\
**Created:** [March 11, 2022, 9:49am UTC](https://forum.elixirforum.com/t/protocols-vs-interfaces/46527 "2022-03-11T09:49:22Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![LostKobrakai](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/lostkobrakai/32/3072_2.png) [@LostKobrakai](https://forum.elixirforum.com/u/LostKobrakai)\
**Post date:** [March 11, 2022, 11:59am UTC](https://forum.elixirforum.com/t/protocols-vs-interfaces/46527/2 "2022-03-11T11:59:09Z")

</div>

While I can see all of your mentioned pain points I don’t think they should be changed. The (primary) interface for a protocol is calling `Prot.to_s` not having a `X.to_s`. I’m not sure why you’d want to have `X.wrap` as a private function in the struct. Either you keep `Prot` and `X` independant, but then X needs to expose all the functionality `Prot` needs (publically) or you don’t and you can just implement `Prot.to_s` directly by moving the implementation of `wrap` into the protocol.

Elixir itself even goes so far in that `DateTime.to_string` and `String.Chars.to_string(date_time)` duplicate the implementation. The latter doesn’t call `DateTime.to_string`.

---

_[View the full topic](https://forum.elixirforum.com/t/protocols-vs-interfaces/46527)._