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

[Gerald Klix]

Hi Hernan,

That's ok.

The implemented behavior mimics Python's in a way, where such warnings 
are shown once for each interpreter start, unless units test are run, 
where every warning is shown.

I like this behavior very much.


Best Regards,

Gerald



On 2020-10-07 23:35, Hernan Wilkinson via Cuis-dev wrote:
> Hi Gerald,
>   I agree with Phil, I think it is not necessary to raise a warning/show a
> debugger when a method is deprecated.
>   Deprecating a method is a meta-attribute that should not interfere with
> the normal execution. Languages like Java, C#, etc. do it that way and I
> think that is the best way to do it. Pharo has the functionality you
> propose but I do not find it useful really.
> 
> Cheers!
> Hernan.
> 
> On Fri, Oct 2, 2020 at 1:44 PM Phil B via Cuis-dev <cuis-dev at lists.cuis.st>
> wrote:
> 
>> 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
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> 
> 
>