On 21 January 2011 23:48, Erik Huelsmann ehuels@gmail.com wrote:
With all these facts on the table, I think we need to do a few things to clean up the mess: - Any condition overriding getMessage() in order to call FORMAT should be removed - getConditionReport() should be documented not to be overridden, but to override getMessage() instead (maybe declare 'final'?) I'd greatly welcome any comments: it's a rather big change, judging by the description above. Ville, you were going to look at it, maybe you can verify if I'm half way right?
First of all, thanks for looking at the mess. Second, you really should leave some bits of the work to the rest of us. :)
Anyway. Some comments, without having looked at the situation in detail: 1) disallowing overriding getMessage() feels wrong. The design may, and likely is, incomplete, but I got a very vague feeling that the function is serving a purpose. Now, I'm not entirely certain whether that purpose exists on the lisp or the java side. I don't have a clear picture of that yet. 2) if getConditionReport is not supposed to be overridden, then YES, absolutely make it final. This actually is a point of endless philosophical language debate. :) But, when we have a language at hand that can do such static semantics checks, let's use the checks and forbid overriding by using existing language facilities.
Off the top of my head, the checklist doesn't look incorrect - I just have some doubts about it. I personally would like to do a bit of fiddling with the codebase, and see if I get the same picture. That will at most take an hour or two, and will probably result in my having a pretty good idea about how to fix the problems.
So, let's give it a timeout of 1-2 days, if I can't produce anything useful within that timeframe, feel free to hack it? :) (I'm exhausted by work, no chance whatsoever to do fun stuff between Mon-Fri).