Defimpl with redefinition overriding existing implementation

riccardomanfrin

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 444 4

2025-12-09 08:10:53 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

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

riccardomanfrin

I as well didn’t very well understand the OrderedObject thing. Or at least I didn’t find it could fit my case.

Let me define the usecase a bit better (and by the way I managed to circumnvent the sorting problem by deserializing the json back into a map at later stage, so this has become more of a general question on why defimpl isn’t doing the job rather than an actual problem).

Suppose I have a tree of maps nested one within each others ad unknown depths:

%{foo: %{bar: %{zoo: :keeper, ...}, ...}, ...}

The Jason.Encoder is taking care of the recursion through the Map types already, so I wanted to exploit it to do other side jobs (e.g. maybe removing a particular key when found in the maps - also in the maps nested within -).

The solution you kindly offered requires me to first iterate the maps to make them into the __MODULE__ struct, which sort of defeats the purpuse (right?)

Post #3

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

— All posts loaded —