Getting the number of indexes in an array.
Has anyone else noticed that since the most recent update, using the select function with the first arg "#" always results in a return value of 1?
Lua Code:
I've had to change to this instead. Lua Code:
|
You need to use select as (select("#", self.Events)) but don't get why would you want to use select in that function.
|
Isn't that what you should be doing anyway?
I mean, this is the documentation I found on using "#" with select, anyway" of wowpedia. Lua Code:
You have a table there instead of a vararg. The number of arguments there in that case would be one. I always had an aversion to using select() anyway. I would do that this way: Lua Code:
|
In this particular case I would just call RegisterEvent 3 times because it's shorter, easier to read, and would use less resources.
Otherwise, pairs or ipairs would be better than getting the length of the table to loop over it. |
Using "#" to get the number of indices of an array was not limited to varargs. It could be used for any array. It just so happens that a vararg expression is an array.
In the example provided, the event list will change depending on several factors which means that I'm unable to just register 3 events. I would do just that, if that wasn't the case. I think it to be good practice to avoid using pairs/ipairs wherever possible. Especially when the function isn't just called once during set-up. Anyone know the better of these two? getn(self.Events) vs #self.Events? I expect it's probably negligible to the point of being irrelevant. Thanks for your input. |
Quote:
That's not true. |
Quote:
|
Quote:
|
Quote:
The only thing wrapping a select call in parentheses does is truncate the list of returns to a single value (the first one returned) but when you're only assigning one variable -- eg. local var = select("#", ...) -- there is absolutely no benefit to or effect from doing that. The only reason to do wrap a select call in parentheses would be to something other than the first returned value, without assigning it to a variable, and in a context where the values passed after the one you wanted would cause problems. For example, if you have the following function: Code:
function GetSomeNumbers() Code:
local _, _, n = GetSomeNumbers() Code:
for i = 1, (select(3, GetSomeNumbers())) do ... Code:
for i = 1, 3, 4, 5 do ... Quote:
Code:
local events = { "one", "two", "three } Code:
local events = { "one", "two", "three } |
Quote:
|
Quote:
|
In case it's still unclear:
Code:
for i = 1, select("#", unpack(self.Events)) do |
I'm sorry but this makes me cringe. :(
After I saw 'for i = 1, select("#", unpack(self.Events)) do' I had to write back! Why not use the standard way of writing a table loop? Code:
local events = {"A", "B", "C"} Code:
function Events() In any case I find this to be a much better approach than unpacking the table to then use select "#" on it to iterate just over the index. |
It seems 3 lines are too much to read, Vlad. What the TE seemed to expect select to return is actually the result of the code snippet I posted. Knowing how unpack works, helps understanding how select works. That was the point of my previous point. Maybe I failed at it, maybe not. I also stated (s)he should not use it like that. So please read before you criticize.
|
To be honest I couldn't quite tell the purpose at first, so I hastily posted what my first gut feeling told me was the right response - sorry if I made you feel bad in any way! :)
|
Quote:
|
If a person comes to a medium for written communication to ask questions, I assume they do read. If they don't, it's all their fault.
|
All times are GMT -6. The time now is 02:45 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI