private vs. protected access

[Søren Hilmer <sh...@itplus.dk>]

Hi,

I propose the following change(s).

Mainly for the supplied matchers and mailets I would like to reconsider having  
instance variables and methods being of private access and move promote them 
to protected access.

Lets take Andreas' DSNBounce as an example of what I am suggesting. Now to 
make this Andreas had to make a change to RemoteDelivery failMessage, but 
failMessage has private access, so Andreas have had to make his own copy of 
RemoteDelivery to make this change, now when RemoteDelivery for some reason 
changes in James, he will have to get this new version and patch in his 
changes (major inconvenience). Now had failMessage had protected access, he 
could just have inherited from RemoteDelivery and overridden failMesssage, 
voila.

The same goes for a lot of the instance variables, when they are private you 
cannot get to them in subclasses (and usually there are no protected set/get 
access methods as well) and it evidently leads to copy paste coding, which I 
consider bad.

As the situation is now, a lot of the mailets/matchers could just as well have 
been declared final.

I won't mind doing the grunt work on this one.

--Søren

-- 
Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 70 27 64 00
TietoEnator IT+		Fax:	+45 70 27 64 40
Ved Lunden 12		Direct:	+45 87 46 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer@tietoenator.com



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org