harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] Proposal for "first-order obvious logic" project
Date Tue, 01 Apr 2008 10:16:03 GMT
Tim, all,

While it would really great to have 100% API implemented, I broke into
a sweat when imagined that the quality of our code base may drop in
result of this approach, if it would not be properly supported with
tests. This especially concerns sophisticated NotImplementedException
implementation which is vulenrable to errors.

I come with an idea how we can handle it. I suggest investing into
automatic tool which would parse bytecode of our methods, make a
control flow graph and create sets of input parameters which would
cover all branches in the code. Then we can run methods with given
parameters and record resulting exceptions or objects (for
non-serializable objects some hash function such as toString() may be
recorded). Finally we can generate a test which would check that the
method produces the recorded result for the set of parameters.

Using this approach we get a test suite with 100% branch coverage and
100% pass rate. Providing this as an argument we would beat those who
might think that "first-order obvious logic" does not give us
compatible and fully tested implementation.

If creating a control flow graph would be to too complex for an
applying student, generating typical corner parameters (such as
objects created by a default constructor) would give us 100% method
coverage quickly.



On Tue, Apr 1, 2008 at 11:12 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> There are a number of interesting student projects being proposed at the
>  moment, and I'd like to add another one for everyone's consideration.
>  It struck me this morning that since we have virtually got the entire
>  platform working well, the remaining pieces could be deduced pretty well
>  by simply describing the expected behaviour using the first-order
>  'obvious logic' principle.
>  Using this principle we would simply write rules for the missing pieces,
>  and implement an inference engine to evaluate these rules to complete
>  the functionality.  While the rules can be written in any language, I'd
>  suggest a good candidate would be the new 'actor participation rules
>  intermediate language 1', and evaluate them using the Java obvious
>  knowledge engine.
>  As an example of the rules we would need:
>    *drag and drop support*  Just implement drag.  After all, once you
>  are dragging something the only option you have is to drop it.  That
>  would be an obvious rule.
>    *rich text format support*  Just implement poor text support and
>  invest in compounding instruments code.  After a few years the
>  compounding effect will make the text increasing richer.
>    *not implemented exception*  Obviously the user's application doesn't
>  want to see this exception.  Rather than throw the exception instrospect
>  the stack and just return an object that will pass the application's
>  validation checks instead.
>  I'm unwilling to mentor the project after today, but if anyone else
>  wants to pick up the 'first-order obvious logic' (FOOL) project, writing
>  code in 'actor participation rule intermediate language 1' (APRIL1) for
>  the 'Java obvious knowledge engine' (JOKE) -- then I'd be facinated to
>  see how well it works!
>  For more information see  http://tinyurl.com/395w9a
>  Regards,
>  Tim

With best regards,

View raw message