On 8/11/11 7:19 PM, [email protected] wrote:
On Wed, Aug 10, 2011 at 6:23 AM, Jörn Kottmann<[email protected]> wrote:
On 8/10/11 2:10 AM, [email protected] wrote:
I think it would be much better, but we have different sample classes (one
for each tool) and no common parent. As far as I can see there is no way
to
compare two samples without knowing the tool and it makes harder to
implement the monitor. That is way I avoided using the sample itself and
added 3 methods that covers different kinds of samples we have.
Ups, accidentally replied to the issues list.
You need to know the sample class, and since they do not have a common
parent you always need to write some custom code to extract the knowledge
from them. This code we have to write somewhere, now it is in the
individual
evaluators, but it could also be moved to command line monitors.
Extracting this information in the evaluators itself, might be a bit easier
since
it is going through the samples anyway.
So going down this road might be a bit more work, but to me it looks like
the
solution is also much more useable.
Maybe we can leave it to a major release and we will have more flexibility
in what we can do. What do you think?
I can also help out here, and if we leave it for later we should maybe
declare new API
as internal use only.
Also to me it is more important to improve dictionary creation to avoid that
errors like the one I was having, so I would choose to spend some efforts
there instead of this. Is it OK?
I worked on making it fail fast, now the POSModel does the same check
independent
of the constructor which was used to create it.
What do you have in mind to ease up dictionary creation?
I also would like to start making the first release candidate, it
doesn't matter
if this change does not go into it, this way we could at least start
testing everything
else.
What do you think?
Jörn
