On the dangers of automated refactoring

Ralph DiMola rdimola at evergreeninfo.net
Wed Apr 14 16:01:02 EDT 2021

Good question... I'm thinking it's the same reason that with strict compilation enabled a variable in a repeat loop does not have to be declared as a script local. If it is declared as a script local no shadow error occurs. A handler parameter in a way is the same as it doesn't need parameters to be declared.

What is the scope of the variable vs. the handler parameter when the handler is running? That's bigger question.

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Alex Tweedly via use-livecode
Sent: Wednesday, April 14, 2021 3:39 PM
To: use-livecode at lists.runrev.com
Cc: Alex Tweedly
Subject: Re: On the dangers of automated refactoring

On 14/04/2021 10:23, Andre Garzia via use-livecode wrote:
> That is the main issue, the code was using the wrong hungarian-lite 
> prefixes. You’d see something like
>    on myHandler pDataA
>>    end myHandler
> But, lo and behold, on top of the script there would be something like
>    local pDataA
> Now, is that an argument to a handler? a script-local? It depends! Strict compilation mode doesn’t care about variable shadowing.

Never mind strict compilation mode, I think this should be a "compile" 
error anyway.

With or without strict-compilation :

   variable shadowing with a script-local and a handler-local is an error.

   variable shadowing with a parameter and a handler-local is an error.

why on earth is variable shadowing between a script-local and a parameter not also an error.


use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the use-livecode mailing list