Modify

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#1233 closed Feature Request (Rejected)

"Deep" global variables not treated as global

Reported by: jchd Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

The following produces 1 warning and 1 error, both unexpected.

main()
Exit

Func main()
	varset(5)
	varview()
EndFunc

;; in large programs, the following would typically be placed in an include file

Global $unseen	;; the parser reads this (but forgets immediately?)

Func varset($val)
	$unseen = $val
EndFunc

Func varview()
	ConsoleWrite($unseen & @LF)
EndFunc

In this situation globals must precede _indirect_ usage, which is annoying. If the parser finds the functions, it should find the global as well.

Is this fixable under reasonnable effort?

Attachments (0)

Change History (4)

comment:1 Changed 15 years ago by Valik

  • Resolution set to Rejected
  • Status changed from new to closed

The script is poorly designed. Remember, AutoIt does not have an entry point which means all code at global scope is executed top-to-bottom as if it were implicitly part of a function. Trying to change the code like you suggest would be a disaster. Imagine code like this:

Global $sFile
GetFileName($sFile)
Global $hFile = FileOpen($sFile)

Func GetFileName(ByRef $sFileLocal)
    $sFileLocal = @TempDir & "\File.tmp"
EndFunc

In that code FileOpen() would be called with $sFile = "" because initializing $hFile has a non-trivial assignment.

comment:2 follow-up: Changed 15 years ago by jchd

No I don't suggest such "batch exec of globals", hopefully.

I'm simply surprised by the error message:

D:\XL Equit\AutoMAT\Test\scope.au3 (20) : ==> Variable used without being declared.:
ConsoleWrite($unseen & @LF)
ConsoleWrite( ERROR

What you say seem to imply that the interpretor performs a text search similar to "\bfunc xyz" when it encounters any invokation to xyz(...) but ignores anything else (or there is a table of known function names at compile time). Then the global def will only be "discovered" when the execution arrives there, if ever.

Is this a (more or less) correct way to grossly describe what the interpretor does?

comment:3 in reply to: ↑ 2 Changed 15 years ago by Valik

Replying to jchd:

No I don't suggest such "batch exec of globals", hopefully.

Then what are you trying to suggest? You're either asking for all global variables to be initialized before any other code is executed or you're asking for global variables to be in scope but uninitialized.

I'm simply surprised by the error message:

D:\XL Equit\AutoMAT\Test\scope.au3 (20) : ==> Variable used without being declared.:
ConsoleWrite($unseen & @LF)
ConsoleWrite( ERROR

Why? At the point of execution the variable hasn't been declared. Are you surprised when this code throws the same error?

MyFunc()

Func MyFunc
    Local $a = $unseen
    Local $unseen
EndFunc

What you say seem to imply that the interpretor performs a text search similar to "\bfunc xyz" when it encounters any invokation to xyz(...) but ignores anything else (or there is a table of known function names at compile time). Then the global def will only be "discovered" when the execution arrives there, if ever.

Is this a (more or less) correct way to grossly describe what the interpretor does?

Why are you talking about functions? A function declaration has no side effects. No code is executed when a function declaration is found. That is not true for variables so you're comparing apples to hang-overs.

Variables may have no initialization, simple initialization (think constants) or initialization with side effects (variable initialized by the return value of a function). That means there may be no code executed, simple code executed, or complex code executed which may or may not change other state information when a variable declaration is found. That means we cannot just stick a name in global scope without performing it's initialization as well. That will lead to attempts to use uninitialized variables which do nothing more than occupy space to suppress an error message. The variable wouldn't contain the expected value which means the script would have a bug in it. A bug that's almost impossible to find because it doesn't generate an error message, as it does now.

I have two suggestions for you. Either replace your calls of "Global" with "Local" and then think about what you see again. Or imagine there is an implicit "Func AutoItMain()" and "EndFunc" around the contents of the file and that AutoIt implicitly invokes "AutoItMain()" for you. In other words, AutoIt's global scope isn't global as it is in a language like C++.

comment:4 Changed 15 years ago by anonymous

In other words, AutoIt's global scope isn't global as it is in a language like C++.

Very clear now. No compilation phase at all, no init on demand.

Thanks.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.