My thought was these methods do not render any direct business services. They are just required by the java framework. If a field is only referenced in these methods, most than likely it was a victim of speculative design or incomplete refactoring. It can and should be removed. Maybe we need an inspection for that... Carlos I agree with a flexible definition of these "inconsequent" methods. And I agree that it might push it a little bit too far ;-) Oh well we are spoiled kids what can I say... We got a perfect toy that keeps on ... perfecting
Jacques "Alain Ravet" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Jacques Morel wrote: > > Why not all canonical methods (equals,hashCode,toString)? > > Because toString() is an exception : > it is frequent/not rare to overwrite it SOLELY to ease debugging sessions. > > On the other hand, equals(), hashCode(), clone(), .. serve a real > purpose, for real usage, by real code. > > > > Jacques Morel wrote: > > Why not all canonical methods (equals,hashCode,toString)? > > > > "Alain Ravet" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > <snip> > >>Request : > >> Add an option to not consider toString() as a field accessor > >> when detecting assigned but never accessed fields. > _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://lists.jetbrains.com/mailman/listinfo/eap-features
