Aim is to localise all the "display" ("render this object human readable") code in one place.
This is by contrast to Option 1 - New human readable options at the top level of every object
Pros
more elegant - fewer methods to have to worry about in each object
helps with mental namespacing (I think that calling "Object.display.name" gets me a human readable name is more obvious than just calling "Object.name" - but the distinction discussed on signal - using magic methods for devs and methods for users - also makes good sense)
keeps objects from being cluttered with methods
makes business logic more clearly distinct from display logic
Cons
marginalises a core part of the functionality of each object - may encourage people to just focus on the business logic aspect of a new class - not the human intractability (on the other hand, this may be a benefit - one dev can work on business logic, the other on human intractability)
arguably less clear
requires a separate system of contracts for what properties display objects have
sonarcloud[bot]
commented
11 months ago 
Aim is to localise all the "display" ("render this object human readable") code in one place. This is by contrast to Option 1 - New human readable options at the top level of every object
Pros
Cons