Ref/rename stream mat

[sleipnir]

@polvalente This PR continues the previous one #418 by renaming GRPC.Server.Stream to GRPC.Server.Materializer as we had previously agreed.

At this moment I am not dealing with anything related to the client. In fact, I wonder if it would be more prudent to break this library into two publishable parts in hex, server and client (but that is a discussion for another time).

This is the relevant commit f90aee1

[yordis]

would this break packages like OTEL?

[sleipnir]

This is definitely a break change from the point of view of the library version. But I don't think it would break OTEL, but we have to check.

[polvalente]

Since it is a breaking change we have to assume it would break.

This change will likely require users to change their code. In multiple places.

[polvalente]

Since it is a breaking change we have to assume it would break.

This change will likely require users to change their code. In multiple places.

[yordis]

• https://github.com/open-telemetry/opentelemetry-erlang-contrib/blob/b22c6cc81e24c2f7ba8a57a40d21a68526432f50/instrumentation/opentelemetry_grpc/lib/opentelemetry_grpc/server.ex#L271

I have come across the pattern matching with such Stream module more than once, plenty to consider this to be a breaking change with high impact

[polvalente]

Even without this example we know this has high impact. The main reason for changing this module is that there are 3 stream modules that will always conflict in naming: GRPC.Stream, GRPC.Server.Stream and Stream from the Elixir stdlib.

Since we are gearing towards v1.0, this is one of the last opportunities we have for renaming this module.

[polvalente]

Even without this example we know this has high impact. The main reason for changing this module is that there are 3 stream modules that will always conflict in naming: GRPC.Stream, GRPC.Server.Stream and Stream from the Elixir stdlib.

Since we are gearing towards v1.0, this is one of the last opportunities we have for renaming this module.

[polvalente]

iex(2)> defmodule M do
...(2)> def foo(%ASDF{}) do
...(2)> :x
...(2)> end
...(2)> end
error: ASDF.__struct__/1 is undefined, cannot expand struct ASDF. Make sure the struct name is correct. If the struct name exists and is correct but it still cannot be found, you likely have cyclic module usage in your code
└─ iex:3: M.foo/1

** (CompileError) iex: cannot compile module M (errors have been logged)
    (elixir 1.18.2) src/elixir_map.erl:33: :elixir_map.expand_struct/5
    (elixir 1.18.2) src/elixir_expand.erl:687: :elixir_expand.expand_args/3
    (elixir 1.18.2) src/elixir_clauses.erl:184: :elixir_clauses.def/3
    (elixir 1.18.2) src/elixir_def.erl:214: :elixir_def."-store_definition/10-lc$^0/1-0-"/3
    (elixir 1.18.2) src/elixir_def.erl:215: :elixir_def.store_definition/10
    iex:3: (module)
    iex:2: (file)

iex(2)> defmodule M do
...(2)> def foo(%s{}) when s in [ASDF] do
...(2)> :x
...(2)> end
...(2)> end
{:module, M,
<<70, 79, 82, 49, 0, 0, 6, 56, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 188,
  0, 0, 0, 20, 8, 69, 108, 105, 120, 105, 114, 46, 77, 8, 95, 95, 105, 110,
  102, 111, 95, 95, 10, 97, 116, 116, 114, ...>>, {:foo, 1}}

For what it's worth, the most likely scenarios where we have where the match happens directly will not fail silently.

[polvalente]

Closing since we'll revisit this soon.