From WoWWiki

It seems like the SetCVar() way to output data is broken since the new patch's release. It only saves data _after_ you log out of the game. Anyone experiencing the same problem in his scripts? Sheepd 12:02, 16 Aug 2005 (EDT)

I believe this is an intended effect (by Blizzard) to sandbox the ui. In a future patch, the SaveBindings() function will probably go away too. --Endx7 12:59, 16 Aug 2005 (EDT)

I really hope they won't do that. Or I won't be able to use that plugin to control my iTunes from within WoW any longer. But thank you for telling me about this SaveBindings() function. Will try that out. Sheepd 18:45, 19 Aug 2005 (EDT)

Variables

I disagree with this new section being here. Firstly, it's not limited to "if" blocks, but rather any block of code where you would be limiting local scope. This isn't really so much of a "quirk" as it is a language feature and the actual definition of scope. This is fully intended. If you wanted to do something like

  if (foo) then
     a = 4;
  end
  DEFAULT_CHAT_FRAME:AddMessage(a);

You will still see "4" in the chat box. The difference is using a variable as local, which always puts it in the most limited scope available to that block. This is the same across all languages.

I didn't delete it as deleting an entire block might be frowned upon, but I do disagree with it being there. Shirik 09:03, 17 March 2007 (EDT)

---

I updated my "Example 1" to point out where the quirk lies. I added it because of my own frustration at wondering why a chunk of code was being ignore while the variables that were being checked held valid non-nil and non-false values.

This is an example of what I'm talking about. Theoretically, this snipit should print two lines with Helm of Lupine Cunning, but it only prints one line. Try it if you dare. :)

Print = function(msg)
    DEFAULT_CHAT_FRAME:AddMessage(msg);
end
-- Just an example (itemName will be "Helm of Lupine Cunning" and itemRarity will be 3).
local itemName, _, itemRarity = GetItemLink("item:25974:0:0:0");
if itemName then
    -- r, g, b, and hex will be whatever they have set for green.
    local _, _, _, hex = GetItemQualityColor(itemRarity);
end
if hex then -- at this point, hex == "1EFF00"
    -- This line will not execute despite the fact that "hex" has a value other than nil or false.
    Print("|cff"..hex..itemName.."|r");
end
-- This line will execute and itemName will be green as expected.
Print("|cff"..hex..itemName.."|r");

Expected:
Helm of Lupine Cunning
Helm of Lupine Cunning

Actual:
Helm of Lupine Cunning

egingell 05:00 18 March 2007 (EDT)

---

I still fail to see how you can call that a "quirk." **You** declared that variable as local. It is acting exactly as you told it to -- a local variable. It operates in its own scope. This is consistent across all languages, and is doing precisely what it is designed to do.

I do hate to sound rude but it really seems to me like you don't understand the purpose behind "local," especially by the examples you've given on the main page. You're declaring a new variable, not setting an old one. That's not a quirk; it's incorrect code. --Shirik 16:30, 28 March 2007 (EDT)

Update: In fact, I removed this portion because it's just plain wrong:

  -- Example 1
  local someVar = true;
  if someVar then
      local someOtherVar = true; -- someOtherVar declared inside an IF block.
  end
  -- someOtherVar *is* set to true at this point, but for some reason the following IF statement ignores it.
  Print(tostring(someOtherVar)); -- "true" is printed.
  if someOtherVar then
      Print("Something"); -- This never gets executed.
  end

It's wrong because... no... "someOtherVar" doesn't even exist, and no, "true" will NOT be printed. There is no such thing as a computer language "ignoring" something because they follow a strict set of rules. They do exactly what you tell them to do. Your problem is you have a variable, "someOtherVar" which is now out of scope. "if someOtherVar" isn't failing because it's false, it's failing because it's nil (and doesn't exist). I removed that statement because it's wrong, and I am going continue to recommend, as I already have, removing the entire section. Proof follows:

  C:\Lua\Lua\BAT>lua
  Lua 5.1  Copyright (C) 1994-2006 Lua.org, PUC-Rio
  > local someVar = true;
  > if someVar then
  >>      local someOtherVar = true;
  >> end
  > print(tostring(someOtherVar));
  nil
  > if someOtherVar then
  >>      Print("Something");
  >> end
  >

--Shirik 16:36, 28 March 2007 (EDT)

---

My apologies. I swear when I had a piece of code written in that manner, it would output what was expected when I didn't check it and produce an error when something was not expected. Sorry if that doesn't make sense. At any rate, I have updated my "quirk". I still feel it should be there as a "need to know". -- egingell 04:32 29 March 2007 (EDT)

We all make mistakes ^^ In any case, after some discussion on #wowwiki we got the idea to write a lua scoping article, and then link to there from here. So I went ahead and did that. Now we have a full and complete article discussing the implications of this problem, rather than just half a statement which would leave some people questioning why it's happening :) Feel free to check it out, Lua_Scope. --Shirik 04:56, 29 March 2007 (EDT)

Cool. That's much better than my clunky code snipit. :) -- egingell 05:19 29 March 2007 (EDT)