Hi Jukka, --- Jukka Santala <[EMAIL PROTECTED]> wrote: > On 30 May 2002, Jim Pick wrote: > > Okay, I applied it, but didn't test it. > > Thanks. I tested it, but I'd also like to comment on > the style, as it was > brought up. I personally prefer self-documenting > code, especially where > comments aren't preferable (interfaces etc.), which > includes fully > qualified names showing where the class members are > coming from even when > they aren't syntaxically required. This tends te > reduce confusion,
I agree. For example, I prefer to use ClassName.method for static methods, although some code in kaffe uses object.method in that case. I think that ClassName.method explains to the reader more clearly that the code is using a static method to perform its task. In the case at hand, I was nit-picking on the MediaTrackerEntry patch. The patch for imageUpdate used ImageObserver.ERROR where the rest of the line used ImageObserver constants without the prefix. But other lines in the class (not touched by the patch) use the prefix, so the implementation left me slighlty confused :). I don't believe we should set a style in stone, but consistency would be nice. In the case at hand, just add the ImageObserver prefix to ALLBITS | FRAMEBITS | ABORT and it's no loger confusing. > although possibly at slight cost to code reusability > (the cut & paste > kind, mainly). However, I didn't bother touching > other people's code to do > that, since as far as I knwo there's no > style-guideliens for Kaffe source, > and the rest of the code was mixing fully-qualified > and relative > references as well. Unfortunately, this probably > leads to worse confusion > than not using fully qualified naems at all, since > the reader is left > wondering why the different way of referring... are > they really the same > after all? right. when you make Klasses using kjc with -w10, you get a lot of code style warnings. Some of them refer to issues similar to the one you describe. > > So, I'd like to propose trying to accept some sort > of style-guidelines for > Kaffe code, for this and other similiar cases. Even > if in the end they > just ended up recommending that people try to use > uniform style within > each class :) Well, the guideline for my ocassional pedantic cleanup patches is: * fix jikes +P warnings. * fix obvious kjc -w10 warnings * remove unnecessary field/variable initialization statements I'd like to propose "compiles with superpedantic options on jikes and kjc without warnings" as the coding standard ;) We can include gcj when it can compile the class library without problems. cheers, dalibor topic __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
