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

[Hernan Wilkinson]

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
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201007/aa885f1b/attachment.htm>