riccardomanfrin

Defimpl with redefinition overriding existing implementation

I wrote a sample module that overrides Jason.Encoder.encode protocol for Map.

defmodule JsonEncoder do
  defimpl Jason.Encoder, for: Map do
    def encode(value, opts) do
      IO.inspect(PASSINGHERE)

      value
      |> Enum.filter(fn {k, _v} -> k != :c end)
      |> Jason.Encode.keyword(opts)
    end
  end

  #test call
  def enc() do
    %{a: 1, b: 2, c: 3} |> Jason.encode!()
  end
end

While doing the same for a custom struct was working, when I do it for generic Map type, it doesn’t.
I can see the compiler detects the redefinition:

iex(8)> recompile
Compiling 1 file (.ex)
    warning: redefining module Jason.Encoder.Map (current version loaded from _build/dev/lib/jason/ebin/Elixir.Jason.Encoder.Map.beam)
    │
  2 │   defimpl Jason.Encoder, for: Map do
    │   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    │
    └─ test/support/json_encoder.ex:2: Jason.Encoder.Map (module)
Generated sampleapp app
:ok

but when I run the test call, I don’t see my code to be triggered.

iex(9)> JsonSortedEncoder.enc
"{\"c\":3,\"a\":1,\"b\":2}"
iex(10)>

What am I missing?

Thanks in advance

4 comments

#jason #map #protocols-and-defimpl

1 290 4

2025-12-09 08:10:53 UTC

Most Liked

LostKobrakai

Overriding protocol implementations is afaik not something elixir wants you to do. I’d stay away from that.

Jason has Jason.OrderedObject — jason v1.5.0-alpha.2 for your usecase.

Post #1

arcanemachine

I was never able to get OrderedObject figured out (and nobody’s ever chimed in with an example), so here’s a homebrewed version of how I sort my encoded maps:

defimpl Jason.Encoder, for: __MODULE__ do
  @doc "Sort keys alphabetically."
  def encode(struct, opts),
    do: Map.from_struct(struct) |> Enum.into([]) |> Enum.sort() |> Jason.Encode.keyword(opts)
end

Note that this would have to be done on a struct-by-struct basis.

Post #2

LostKobrakai

The usecases of Jason.OrderedObject are kinda twofold. The primary usecase is allowing minimal modifications to existing json strings. That includes not arbitrarily reordering object keys. So on decoding you can add an option so objects are decoded as ordered_objects, so they can be encoded back into the same order, while allowing modification between.

You can however also use Jason.OrderedObject to create ordered objects if you’re dealing with a consumer, which for whatever reason depends on order in objects even though they shouldn’t.

json = """
{
  "c": 1,
  "b": 2
}
"""
|> Jason.decode!()
|> Jason.encode!()
# "{\"b\":2,\"c\":1}"

json = """
{
  "c": 1,
  "b": 2
}
"""
|> Jason.decode!(objects: :ordered_objects)
|> Jason.encode!()
# "{\"c\":1,\"b\":2}"

for i <- 0..36//1, into: %{} do
  {"a_#{i}", i}
end
|> Jason.encode!()
# "{\"a_2\":2,\"a_13\":13,\"a_8\":8,\"a_26\":26,…}"

for i <- 0..36//1 do
  {"a_#{i}", i}
end
|> Jason.OrderedObject.new()
|> Jason.encode!()
# "{\"a_0\":0,\"a_1\":1,\"a_2\":2,\"a_3\":3,…}"

Given the choice of words I guess you’re already aware that this is not necessarily a great idea. Protocols are globally registered. Using it for none general behaviour will be bad for the next person, who doesn’t need your side jobs to apply – requiring them to add even more hacky overrides over your hacky overrides to get rid of them. If you want to go that route I’d strongly suggest using elixirs JSON if you can. It allows adjusting how data is encoded as a function parameter, which can compose multiple behaviours better than just relying on protocols.

Post #4