creadur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [GSOC] Rat: Past, Present and Future
Date Mon, 08 Jul 2013 20:41:58 GMT
On 8 July 2013 20:46, Robert Burrell Donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
> The Past
> --------
> (Here's my perspective on the history of Rat, as I recall it now. Hopefully
> it isn't too controversial. Please feel free to jump in with
> clarifications...)
>
> Rat arose from an itch of mine, and I coded the core of Rat as an
> experimental project, playing around with some unconventional architectural
> ideas. With hindsight, once other people wanted to start using it too, I
> really should have just sat down and completely rewritten the core code. By
> not doing so, I inflicted a world of craziness and pain on the community and
> ecology which sprang up around Rat. But by then, it had become hard to fix
> as higher quality peripheral code sprang up around it. Apologies.
>
> The Present
> -----------
> Thanks to Manuel Suárez Sánchez and GSOC, we have an opportunity to adopt a
> more sane and sensible core design with good test coverage that will be
> easier and more enjoyable to maintain and comprehend going forward.
>
> AIUI Google likes to be able to access a copy of the GSOC code, so I've
> suggested that Manuel codes on GitHub
> (https://github.com/elnuma/creadur-rat). Hopefully, this should allow people
> with GitHub forks (mine is https://github.com/itstechupnorth/creadur-rat) to
> pull in Manuel's code and give encouragement and advice. Apache has recorded
> an ICLA for Manuel, so when we're ready we should be able to start patching
> in pull requests.
>
> The Future
> ----------
> (Bit of a strawman - hopefully the community - including Manuel - will dive
> in with suggestions and we'll be able to gain consensus on a design
> direction...)
>
> ...
>
> I wonder whether it would be simpler and more conventional to factor out
> three phases:
>
> 1. scan the source, building a strongly-typed, immutable domain model
> 2. analyse this model against policies, building a strongly-typed, immutable
> report model

Won't that require lots of memory?
At present the source can be forgotten as soon as a match occurs.

> 3. use the report to output descriptive text or XML, or errors and warnings
>
> I also think that Rat would benefit from
>
> * using more conventional dependency injection (see, for example,
> http://www.martinfowler.com/articles/injection.html) replacing the static
> methods that litter the code
> * immutable domain objects with builders
>
> Opinions...? Improvements...? Objections...? Alternatives...?
>
> Robert

Mime
View raw message