Consider a `Module` to be displayed similar to a `Class`, as a "primitive"

[phorsuedzie]

SuperDiff version: 0.12.1 (newest release available)

An inspected Module is not displayed with its name, but with its instance variables etc. (by ...::InstanceTreeBuilders::DefaultObject).

This is different from a Class, which is a SuperDiff.primitive?, and therefore displayed by ...::InstanceTreeBuilders::Primitive, with (only) its name.

The ugly output can be seen at an RSpec example description (rspec --format doc ...) that is auto-generated from a be_a matcher:

it { is_expected.to(be_a(TaskJob)) }

is shown as

is expected to be a kind of #<Module:0x00000001183d33f8 @_dependencies=[], @_included_block=#<Proc:0x000000011941db78>>

If (only) either SuperDiff.primitive? or Primitive.applies_to? is patched to (additionally) return true for a Module === value, then the output looks better:

is expected to be a kind of TaskJob

[jas14]

@phorsuedzie thanks for highlighting this, and for the small reproducible test case!

As you note, we fall back on the DefaultObject inspection tree builder, which shows the class (ironically Module) and the object address. It looks like the object inspection in rspec-support just calls #inspect on the module, which yields its name.

Confirming what you said, we already have a Primitive inspection tree builder, so we'd just need to add Module to the primitive list and add some unit and integration tests. I'm marking as a good first issue, PRs welcome!