Re: [patch #2388] DefaultTableCellRenderer update

[Michael Koch]

On Mon, Jan 12, 2004 at 04:18:00PM +0100, Arnaud Vandyck wrote:
> Michael Koch <address@hidden> writes:
> 
> > On Mon, Jan 12, 2004 at 03:32:35PM +0100, Arnaud Vandyck wrote:
> >> Michael Koch <address@hidden> writes:
> >> > - no changelog entry
> >> And what is this?
> [...]
> > Oh, I totally overlooked this.
> NP.
> 
> >> > - we dont wanna add stubbed methods anymore. Either implement it or
> >> > leave it out.
> >> 
> >> Sorry if I left a stub method... Which one? Lot of methods in this
> >> component are empty because they override parent and they DO NOTHING
> >> (it's the way they are! because it's the table that make the renderer)
> >> 
> >> ... if I understood it right! ;)
> >
> > If thats the case the you should really add this as comment to method
> > like this:
> >
> > public void foobar()
> > {
> >   // This methods needs to be overridden in subclasses to actually do
> >   // somthing.
> > }
> >
> > A comment in the method documentation can't hurt too but "Does nothing."
> > is a little bit short and undesciptive why this method does nothing.
> 
> Yes, I should comment, sorry. The fact is some methods in this component
> are overriden because it's the table that does redraw all the components
> and if each component redraw it self, it'll take too much time.
> 
> I thing I still have some mails that explain exactly what happens (some
> devs on this list helped me).
> 
> You know Mark, it took me a long time to understand and to implement
> (event empty methods because I was not sure I have to leave it empty)
> and I really want a working swing implementation, not just a library to
> compile (but not to run). Believe me, when I do send a patch, I try that
> it's really useful ;)... even if I make mistakes ;)
> 
> I already do follow your coding standards, next time, I'll comment my
> code ;)

No problem. Will you update your patch or should I do it ? Then the
patch can go in.


Michael