[Aptitude-devel] 002-qt-stubs review

[Daniel Burrows]

On Wed, Jul 14, 2010 at 3:01 PM, Sune Vuorela <nospam at vuorela.dk> wrote:
> Rather than playing theoretical games, we should also make sure that we
> actually get something done in a useful way.
>
> Just because you *can* insert bunches of abstract interfaces in between
> things doesn't mean you *should*.

  Sure, and just because you can choose not to doesn't mean you
shouldn't.  Splitting your code up in sensible ways can make it more
maintainable, splitting it up badly makes it less maintainable.  Writing
unit tests for code where they make sense makes sense, writing them
when they don't make sense doesn't make sense.

  More of the sorts of generalities I was trying to avoid by asking for
specific, practical examples.

  I'm not throwing a bunch of design ideas out there to play mind
games, I'm doing it to understand what sorts of designs we can get
to with the qt code and how to get there.  I'm also trying to make
sure that the qt frontend is reasonably integrated with the overall
design and code style of aptitude, rather than being a redheaded
stepchild grafted onto it like a bastardised, badly mixed metaphor
from the planet Q.  I want to know what the boundaries are as far
as how far we can push the design in various directions, and the
only way I know to do that is to ask whether we can do X or Y in a
Qt program and how ugly it would be to try.

  As far as abstraction layers go, I've written code in the style I'm
suggesting before.  It works, and it's really nice to be able to write
tests for parts of the UI that are traditionally not accessible to
automated tests without complicated and flaky harnesses that
drive the full program from test code.

  I certainly understand why you're worried about having too much
architecture; Arthur can tell you about some of my rants on
overengineering in the past.  The *only* reason I started using
abstraction layers this way is that I saw *practical* benefits from
them, particularly around testability and maintainability.  I guess
you could consider testability an impractical goal; I don't, and I
consider it to be especially important if the number of people
working on this code increases beyond 1.


  And since I don't know if I said this clearly before: I am *not*
requiring Piotr to adopt all my design ideas to accept his code.
There may be some specific ideas that I do care strongly about,
but most of my suggestions are really just suggestions that I'd
like him to consider.

  Daniel