Newbie... Strict Compilation mode

Graham Samuel livfoss at mac.com
Sun May 10 05:18:54 EDT 2009


I think all this proves that different people can and do use  
Revolution / xTalk differently. Personally I am persuaded by Jim's  
argument, and indeed I have changed: when I first came to xTalk after  
years of using languages where declaration of variables was mandatory,  
I relished the freedom of not having to do so. But gradually I got  
tired of debugging my own spelling mistakes and moved over. However I  
have enormous respect for the Jacque and Richmond, who are clearly  
highly productive NOT using Strict Compilation, so I'm glad there are  
the two ways of doing it...

BTW I can't quite follow Richmond when he says

> Funny, I've never declared a variable in Runtime Revolution

Do you never carry values from stack to stack or handler to handler  
via globals? Maybe you always use custom props. But AFAIK, when you  
write:

  put "Richmond" into myGlobal

in a handler without a corresponding 'global' declaration, and then in  
another one in a different galaxy, far away, you write:

  put myGlobal

you won't see "Richmond" in the message box, will you?

As an aside, I noticed that if I start a repeat statement with  
something like:

  repeat with i = 1 to 20

even with ExplicitVars on, the local variable "i" does not have to be  
declared. I could not find an explanation of this in the docs, but  
perhaps I didn't look hard enough. I admit I find this useful, but  
then I am a convert as explained.

Graham


On Sat, 9 May 2009 13:56:11 -1000, u "Jim Bufalini"  
<jim at visitrieve.com> wrote:
>
> Richmond Mathewson wrote:
>
>> May be this is a goofy question; but it can probably bear
>> the asking one more time:
>>
>> What, if any, is the advantage of declaring variables in RR ?
>
> - Unles yu ar an perfct typst who has nevr made a typo and nevar use  
> a speel
> checker, explicitVariables instantly indicates a speling eror at  
> compile tim
> and alows you too quikly corect.
> - This is also very helpful to people to whom English is a second  
> language
> and English spelling is not intuitive and they can and often do put  
> one r
> or l in one place and two r's or ll's in another and other such  
> typical
> English spelling errors.
> - It allows you to distinguish globals from script locals and  
> constants both
> at the script level and handler level.
> - It allows you to declare globals from inside a handler (which  
> creates a
> "semi" global that is only available to other handlers that also  
> declare the
> same global).
> - It makes your code much more readable, not only to others, but to
> yourself, when you are troubleshooting a problem weeks or months or  
> years
> later.
> - It is "polite" to others with whom you may want to share your code  
> and
> they have explicitVariables turned on. They are not going to turn it  
> off for
> a large project just to look at few lines of your code.
> - If you use GLX2, it allows GLX2 to offer you variable completion  
> after
> typing four chars of a declared variable name.
> - The reason the name was changed is probably because it also checks  
> that
> you have not spelled reserved words incorrectly. *set the locaton of  
> this
> stack to screnLoc* will not give a compile time error if Strict  
> Compilation
> Mode is turned off. If it is on, you get an error. If you are just  
> learning
> the language, this is big help.
>
> Lastly, although you can "create" variables without declaration, the  
> fact
> is, variables cannot be created on-the-fly at runtime. Only array  
> variables
> and custom property variables can be created on-the-fly. Otherwise,  
> you must
> use a *do* statement, which has limitations, is slow because it is  
> complied
> at runtime  and can be tedious and error prone to write a long one.  
> All
> other variables are whatever you typed on compile.
>
> So, given these facts, the real question is:
>
> What, if any, is the advantage of NOT declaring variables? ;-)
>
> Aloha from Hawaii,
>
> Jim Bufalini




More information about the use-livecode mailing list