<div dir="ltr"><div dir="ltr">Gerald,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 2, 2020 at 7:23 AM Gerald Klix <<a href="mailto:cuis.01@klix.ch">cuis.01@klix.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-10-01 22:29, Phil B via Cuis-dev wrote:<br>
> Juan,<br>
> <br>
> On Tue, Sep 29, 2020, 11:11 AM Juan Vuletich via Cuis-dev <<br>
> <a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br>
> <br>
>> What do others think? Isn't it enough with keeping a Transcript open<br>
>> when developing?<br>
>><br>
> <br>
> The main thing I need is to just be able to find deprecated methods in<br>
> code.  I usually don't want to see transcript warnings, debugger pops from<br>
> exceptions etc.  I'm fine with whatever functionality others find useful as<br>
> long as there's an easy way to turn it off.<br>
As I pointed out, that could be done easily by just changing a <br>
preference to false. However you will see them in your unit tests.<br>
<br>
Personally I don't want to see such clutter,<br>
expect when I am testing, but that's just<br>
my 0.02€.<br></blockquote><div><br></div><div>I wouldn't generally want to see them in unit tests either.  I typically use deprecation flags (not notifications/warnings) for two reasons:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Phil</div></div></div>