I'd like to second the opinion that deprecated still works (until
removed), but is discouraged from use. I believe that is what Andrus
intends, though, given previous API changes.
On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <mkienen..mail.com> wrote:
> 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:36:37 EDT