Glynn, Eoghan wrote:
*snip*
As I said I'm agnostic to the PMD rule change.
However, I really don't see why there's such a big bones about giving
the user a *choice* between implementing an interface and extending an
abstract class. Especially since the class that started the whole
debate, Polar's HttpBasicAuthSupplier, has such a tiny amount of
implementation code in the base class.
Which now that I look at it again, I notice isn't even abstract.
Well, first of call CXF doesn't have this/my patch to look at yet.
Second of all, I was forced to make it a fully implemented class to
avoid having "AbstractHttpBasicAuthSupplier" in my code, which is really
what we are talking about. And that's what I am objecting to, is the
rule is forcing me to do bad things.
I'm going back to making that class abstract. please.
Cheers,
-Polar
Which
is odd, as having a default null-returning impl for
getUserPassForRealm() can't be for backward compatability (as we know
this method exists right now), and the user sortta has to override it
(otherwise their HttpBasicAuthSupplier is kinda useless). Plus the PMD
rule at issue doesn't even apply to HttpBasicAuthSupplier as its
non-abstract. So I'm a bit confused now about what we're even arguing
about ...
One advantage of these automated rules is to head off religious debates
on code style. I guess we loose that if we start endless debates about
changing the rules. But I'm also really tiring of this debate, so lets
just draw a line under it ...
/Eoghan
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
