Am 24.01.2014 16:15, schrieb Tim Starling:> On 24/01/14 15:11, Jeroen De Dauw wrote:
Daniel proposed an ideal code architecture as consisting of a non-trivial network of trivial classes -- a bold and precise vision. Nobody was uncivil or deprecating in their response.
This idea is something that grew in my mind largely through discussions with Jeroen, and the experience with the code he wrote for Wikidata. My gut feeling for the right balance of locality vs. separation of concerns has shifted a lot though that experience - in the beginning of the Wikidata project, I was a lot more skeptical of the idea of "separation of concerns". Which doesn't mean I insist of going down that road all the way all the time now.
I would like to take this opportunity to thank Jeroen for his conviction and the work he has put into showing that DI and SoC actually make work with a big code base less cumbersome. Without him, we would have copied more problems present in the core code base.
One big advantage I want to highlight is confident refactoring: if you have good, fine grained unit tests, it's easier to make large changes, because you can be confident not to break anything.
Am 24.01.2014 14:44, schrieb Brad Jorsch (Anomie):
It looks to me like the existing patch *already is* getting too far into the Javaification, with it's proliferation of classes with single methods that need to be created or passed around.
There is definitely room for discussion there. Should we have separate interfaces for parsing and formatting, or should both be covered by the same interface? Should we have a Linker interface for generating all kinds of links, or separate interfaces (and/or implementations) for different kinds of links?
I don't have strong feelings about those, I'm happy to discuss the different options. I'm not sure about the right place for that discussion though - the patch? The RFC? This list?
Am 24.01.2014 15:56, schrieb Tim Starling:> On 24/01/14 11:19
The existing patch is somewhat misleading, since a TODO comment indicates that some of the code in Linker should be moved to HtmlPageLinkRenderer, instead of it just being a wrapper. So that would make the class larger.
Indeed. HtmlPageLinkRenderer should take over much of the functionality currently implemented by Linker. The implementation is going to be non-trivial. I left that for later in order to keep the patch concise.
-- daniel