[kaffe] MediaTracker

[Dalibor Topic]

Hi Jukka,

--- Jukka Santala <jsantala at tml.hut.fi> 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