[Cuis-dev] [IMPROV] Testing and Debugging Deprecated Methods

[Phil B]

Gerald,

On Fri, Oct 2, 2020 at 7:23 AM Gerald Klix <cuis.01 at klix.ch> wrote:

> On 2020-10-01 22:29, Phil B via Cuis-dev wrote:
> > Juan,
> >
> > On Tue, Sep 29, 2020, 11:11 AM Juan Vuletich via Cuis-dev <
> > cuis-dev at lists.cuis.st> wrote:
> >
> >> What do others think? Isn't it enough with keeping a Transcript open
> >> when developing?
> >>
> >
> > The main thing I need is to just be able to find deprecated methods in
> > code.  I usually don't want to see transcript warnings, debugger pops
> from
> > exceptions etc.  I'm fine with whatever functionality others find useful
> as
> > long as there's an easy way to turn it off.
> As I pointed out, that could be done easily by just changing a
> preference to false. However you will see them in your unit tests.
>
> Personally I don't want to see such clutter,
> expect when I am testing, but that's just
> my 0.02€.
>

I wouldn't generally want to see them in unit tests either.  I typically
use deprecation flags (not notifications/warnings) for two reasons:

1) So I can periodically proactively look browse a list of deprecated
things and see what's using it.  It is during these times that I may want
to enable noisier functionality to log/raise exceptions/fail tests/whatever.

2) Let's say I didn't do 1 in a timely manner and a new release comes out
which breaks things.  At that point I can pull up the last known working
image/package browse to the no longer available class/method and see that
it was deprecated to know it was on me to stop using it.  This prevents me
from sending a ranty complaint to the list as I know what I need to do to
fix the issue.

The problem I have with intrusive (logging, exceptions, unit tests...
whatever) deprecation notifications always on is that I usually need to
continue to use the deprecated code for a period of time, but still
want/need to update the image to adapt to other ongoing changes, before I
fix it.  During that period, I don't want my code stopping or significantly
slowed down.  Deprecation should behave more like documentation than an
error/warning.  It's fine if it can *optionally* be an error/warning for
those who like that, but it shouldn't be forced on you.

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201002/6aecc72f/attachment.htm>