msgpack-ruby | MessagePack implementation for Ruby / msgpack.org | Performance Testing library

As of right now (version 1.2.4 of msgpack-ruby) this is not possible in the exact fashion you tried: the msgpack_packer_write_value function first checks all hard-coded data types, and handles them with its default implementation. Only if the current object does not fit any of those types are the extensions handled.

In other words: you cannot override the default pack formats with MessagePack::DefaultFactory#register_type, calling that will simply be a no-op.

Furthermore, the extension mechanism is not what you are looking at, anyways. Using that, messagepack would emit a marker byte "this is an extension", followed by the extension ID (the value "0" in your example), followed by what is already encoded as float32 - alternatively you would need to handle the binary encoding/decoding yourself.

You could, in principle, create your own FloatX class or whatever, but this is just a very bad move:

• Float has no new method which you could monkeypatch, and I know of no way to tell ruby to create a FloatX instance when you write 10.3 in your code. So you would have to do manual object creation throughout your code, probably with severe impact on performance.
• You would end up with the extension mechanism anyways, infeasible as shown above.

You would need to to override the msgpack_packer_write_value implementation of packer.c. Unfortunately you cannot do that in the ruby world since there is no equivalent ruby method defined for it. So the usual monkeypatching of ruby cannot be used.

Also, the method is called from plenty of other methods inside the packer.c implementation, for example in the respective methods responsible for writing arrays or hashes. Those of course would not call a ruby method of the same name either, as they're living in their binary world completely.

Finally, whily the usage of a factory mechanism seems to imply that you can somehow create different implementations of packers, I see no evidence that this is actually true - reading the C code of the Gem, there seems to be no provision for anything of that kind. The factory seems to be there to handle the ruby<->C interactions of the Gem.

If I were in your shoes, I would clone that Gem and modify msgpack_packer_write_value in packer.c to behave as you wish. Check the case T_FLOAT and go on from there. The code seems pretty straightforward - it soon proceeds to the following method in packer.h: