Talk:API and scripting quirks

SetCVar
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)

Scope
Sorry if I'm a tad late to the party here (just got into WoW UI coding), but I was a little confused by the "quirk" where a local variable declared inside a block didn't exist anymore after that block went out of scope. I was thinking that having this listed as a "quirk" will cause confusion rather than giving insight. I can totally understand that less experienced programmers may not be familiar with basic scoping rules and I'm not trying to offend anyone at all; but I just think this type of info isn't necessary here since it is assumed readers will at least have basic knowledge of the scoping rules used by the vast majority of programming languages. --Spynesso (talk) 22:41, 1 June 2009 (UTC)


 * My opinion is that most of this page is unnecessary at best and outright wrong at worst. Luckily, virtually nothing links here, so it's not that big a problem. I'd suggest simply removing things you do not consider useful (or find not to be, well, true) from this page, and integrating the remaining information into other pages that deal with the related functions/API area. -- foxlit (talk) 23:42, 1 June 2009 (UTC)


 * You may not think it important, but someone who has little to no experience with Lua might be confused as to why their variables aren't being read like they think they should or would be in a less scope-strict language.


 * My heart bleeds for the people who use the local keyword without understanding what it means. However, I wouldn't call Lua's lexical scoping a quirk: it is well documented, both in the Lua documentation and at Lua variable scoping. I also dislike the "think of people with little to no experience" argument in general: those people need an introduction to the subject, not a list of potential misconceptions arising from not doing their homework. -- foxlit (talk) 18:02, 2 June 2009 (UTC)


 * The addition of that "quirk" actually led to the creation of that page. lol