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? 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?
