I guess my problem is that to me..eprecate means "it still works like
it used to, but it won't work in a future version and it's time for
you to change your code", but that's not what's going to happen here.
That's why if we're not really..eprecating it but crippling it, then
I'd recommend removing it. Giving end-users the false-hope that
things are working as usual isn't very nice.
You know the details of this particular situation better than I do,
though. If you don't think silently doing nothing will affect
expected program behavior, go for it.
On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
> On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
>
>
> > To me, that sounded like you were going to change the behavior rather
> > than just mark the method as..eprecated.
> >
>
> I was planning to do both. Although we may decide to be gentle about it and
> deprecate the method, but preserve the functionality (which will put a bit
> of extra maintenance burden on us).
>
> I am leaning towards the first option (deprecate and stop invoking),
> especially since the nature of the change results in enhanced data
> consistency, so there won't be any unpleasant surprises.
>
> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Mon May 05 2008 - 16:03:05 EDT