Modify

Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#420 closed Bug (No Bug)

Scope bug or mis-wording in documentation

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

Description

As shown in this thread-
http://www.autoitscript.com/forum/index.php?showtopic=74486

The For-Next loop does not always create variables in the local scope as defined by the help file. In particular, it seems to only create a local variable when the For-Next loop is in a function, but creates a global variable when the loop is outside a function.

If it is intended behavior, a slight re-wording of the help file seems in order. As it stands now-

Remarks

The Variable will be created automatically with a LOCAL scope, even when MustDeclareVars is on.

Attachments (0)

Change History (7)

comment:1 Changed 16 years ago by Valik

  • Resolution set to No Bug
  • Status changed from new to closed

It is created with local scope. And local scope at the global level means the variable is globally visible. What else would you expect?

Not a bug, doesn't need documented, just need user's to turn their brains on and think things through for once.

comment:2 follow-up: Changed 16 years ago by evilertoaster

I would expect it to behave like VB 2005 not VB 6.0 (which was generally considered non-standard) as defined here-
http://msdn.microsoft.com/en-us/library/bybkyxaz(VS.80).aspx

It it generaly more accepted to have variables be local when delcared inside thier own 'block'. I would highly recommend looking at this agian.

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

Replying to evilertoaster:

I would expect it to behave like VB 2005 not VB 6.0 (which was generally considered non-standard) as defined here-
http://msdn.microsoft.com/en-us/library/bybkyxaz(VS.80).aspx

I would expect it to behave like we wrote it. Because, you know, we wrote AutoIt and it's not VB. Maybe that's your problem? You're expecting AutoIt to be something or behave like something it isn't.

It it generaly more accepted to have variables be local when delcared inside thier own 'block'. I would highly recommend looking at this agian.

Except that AutoIt doesn't have scope blocks other than "Global" and "Function" level scope.

Nothing needs done. Everything is working exactly how it's intended to. Your expectations are wrong.

comment:4 Changed 16 years ago by anonymous

I would expect it to behave like we wrote it. Because, you know, we wrote AutoIt and it's not VB. Maybe that's your problem? You're expecting AutoIt to be something or behave like something it isn't.

I made no particular assumptions for what you'd expect as a developer per-se.
However, I would think most programmers would find this very counter-intuitive and non-standard compared to other languages. I don't expect it to behave exactly like VB either, nor would I want it too. There are programming conventions that are followed by nearly every modern language though, and I think having a local scope as a pseudo-global scope deviates from this... I can't think of another language that treats it as such off the top of my head.

Except that AutoIt doesn't have scope blocks other than "Global" and "Function" level scope.

I know :(

Nothing needs done. Everything is working exactly how it's intended to. Your expectations are wrong.

That's always your decision, I can only recommend you not be so dismissive about it, I only point it out because I personally think it would be better for AutoIt, but I'd at least encourage discussion about this among you developers... The end choice is always yours. From a programmers perspective though, this would really be one of the only things of AutoIt that just seem 'wrong' in its public implantation.

comment:5 Changed 16 years ago by evilertoaster

My comment above, just for clarification-

comment:6 Changed 16 years ago by Valik

What makes you think we haven't talked about it? Besides, it's a little late in the game to go and change things now. Many scripts would be broken if scope suddenly got more granular. I can't say that all the code that would be broken is good code, but never-the-less, much code would be broken for very little reason. Most people don't even realize AutoIt *isn't* block-scoped so this isn't as critical an issue as you're making it out to be.

By the way, the very reason you found the "bug" in the first place is because you're using what I'd consider a far worse "feature" of AutoIt. That being we don't enforce an entry-point function which means you are free to write any code at global scope. If you're so concerned about scope issues, then I would think you'd come up with your own personal convention like I have where you never have code at global scope unless it's part of a variable definition.

comment:7 Changed 16 years ago by evilertoaster

I'm not sure one way or the other if you have or to what extent you've talked about it internally, I didn't see anything suggestive when I searched about it initially...
I can definitely understand not wanting to create a headache of more script breakers this late in development though. I'd think it more important convention-wise than the ones done last May, but I guess if you've weighed it against the trouble it would cause for old scripts then it could also be more significant.

The example script was a much simplified case; the original discovery was from a local->'block local' instead of a global->local. The no-entry point is probably not ideal, but I think it's somewhat common in scripting languages...I'd tend to disagree about it being 'far worse'.

Anyways- if it has already been discussed at length then there's no use me continuing other than to be a voice for the side of changing it and to have some archived note of it somewhere. It's fair to say you know what you're doing at this point :)

Thanks for your time-

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.