cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Checkstyle
Date Wed, 04 Apr 2007 20:23:55 GMT
 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 04 April 2007 19:17
> To: cxf-dev@incubator.apache.org
> Subject: Re: Checkstyle
> 
> On 4/4/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > So the abstract base class is in my view a convenience that 
> the user 
> > may choose to take advantage of, or not, as the case may 
> be. But they 
> > should not be forced to do so. So AbstractWSFeature is 
> grand, as long 
> > there's also a WSFeature interface that the user can choose to 
> > implement directly.
> 
> 
> The whole point is to not have an interface for forward 
> compatability so users don't shoot themselves in the foot.


Or that we don't shoot them in the foot by extending the interface? :)

 
> For instance, JAX-WS has Endpoint, Service, Provider, and 
> ServiceDelegate.
> Can you imagine how awkward it would be for users if they 
> were using AbstractEndpoint all the time? Interfaces for all 
> these classes would be completely redundant/useless for users as well.
> 
> Anyway, I don't really feel like arguing this anymore, but I 
> agree with Polar and I think we should make the change. This 
> really won't harm anyone, and will only serve to make our 
> code clearer.


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. 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
> 

Mime
View raw message