There are 53 getSender() strings in v2:
43 in matchers/mailets
24 in the AbstractRedirect hierarchy
19 in other matchers/mailets
10 in 4 modules.
There are 6 setSender(...) strings in v2:
3 in matchers/mailets
3 in the AbstractRedirect hierarchy
0 in other matchers/mailets
3 in 1 module.
As this point comes from discussions over the AbstractRedirect hierarchy classes, that
I'm for now modifying, I would easily change it there in one shot, but I think that it
would be very cumbersome to continue to keep by hand the sources different in v3 from
v2 just for this in 27 points.
And in general, the effort of a one shot overall change is minimal, while to maintain
the two versions different on an ongoing basis is IMHO much higher.
Secondly, we could insert the new Mail.getReversePath/setReversePath methods in both
versions and deprecate Mail.getSender/setSender only in v3 for now (to avoid too many
deprecation warnings in third party mailets).
So for me it's +1 if we change it in both versions (with or without a v2 deprecation),
but -0 if we keep it different.
Vincenzo
> -----Original Message-----
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]
> Sent: martedi 1 luglio 2003 3.36
> To: James Developers List
> Subject: Re: Deprecate Mail.getSender/setSender
>
>
> Noel J. Bergman wrote:
> > I propose that we deprecate Mail.getSender/setSender in favor
> of unambiguous
> > names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
>
> Works for me. +1. This would likely need to be applied only to the 3.0
> branch though.
>
> --
> Serge Knystautas
> President
> Lokitech >>> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
