[Solved] Wildcard index for a table

[PiFace]

Well, now I'm using rawget instead of comparing to the default value. It does the same as before (without the metamethod), but there's no need to do any other checks through the code.

Like:

Code: Select all

...
if not rawget(imgTable,v) then
...

[raidho36]

In your case that's equivalent to:

Code: Select all

if not imgTable[v] then

Without having to implement everything else.

[pgimeno]

There's one easy way to check if an element is really empty. rawget(table,index) will tell you that.

Edit: Seems I missed this page when I posted. Sorry. Showing the pager well below the last post confuses me.

[Positive07]

I would go with the [manual]setmetatable[/manual] __index method and use [manual]rawget[/manual] if I want to check if am index is empty.

Why? Well clarity of code. If performance is not a concern (and really you shouldn't bother about performance unless you are really having performance issues) then you should try to write code which is easier to change, debug and read.

Having ors everywhere is not nice, you may forget one and you will have it wrong. There are probably much less ocations where you actually want to check if the index is empty, and calling [manual]rawget[/manual] there won't hurt. This function is there for a reason.

Other alternative solution would be to implement a default function that does

Code: Select all

defaultvalue = 1

function default(tab, index)
   return tab[index] == nil and defaultvalue or tab[index]
end

And you would use them similar to how [manual]rawget[/manual] works but in the places where you need to use the default value, basically you would be replacing the ors everywhere in your code with this function, then if you need to change how this function works or what is the defaultvalue you change it in one place.

Sine you may need to call this operation many more times that you would call [manual]rawget[/manual] if you were using the [manual]setmetatable[/manual] method I think the [manual]setmetatable[/manual] method is better. Lua has all this things for a reason.

[raidho36]

Both variants will probably perform equally (maybe metamethod one is a bit slower due to function call overhead), but I disagree with the notion that there is ever a situation where performance is not a concern. In enterprise it may be cheaper to lend a bigger server cluster than to have the programmer optimize the software, but it all boils down to balance between labor costs and hardware costs. On the desktop you don't have the benefit of virtually unlimited computational power, so having it run well as it is is of great importance. And on mobile in particular, every last bit of performance counts because better performance = longer battery life. I also disagree with the notion that "it's not a performance problem until you can clearly see it". It's never early to plan ahead, and it's never smart to neglect repercussions until they come to bite you in the ass. As the saying goes, he who laughs at ounces cries over pounds. So if you leave be some poorly running bits of code here and there, the next thing you know the whole thing runs poorly and you have to fix everything in it to get it to run better. If you arrive at that point, resolving bottlenecks is but a band aid to a dead man - the core of the issue is that it's just not built to run fast, and so it wont.

Having that said, I wouldn't waste __index on something as trivial as default value.

Code: Select all

value = table[key] or table.default

And I find using default value explicitly to have a lot better clarity than having it returned implicitly. Given big enough project, it's easy to forget some details, and being able to infer exact algorithms and pathways from immediately visible source code alone is the whole reason why you need code clarity. Having black boxes and implicit activity all over the place is opposite of clarity, it's obfuscation.

[Positive07]

Well that is your opinion though. To me (and probably the rest) writing good code is better than losing time debugging optimized code. I can optimize later once it works, and it will probably crash but debugging will be easier, since I know what changes I made to break it.

Also about code clarity and black boxes, that is the reason I suggested the default function, it may be a method of a library or something, you know what it will do

Changing all default values throughout code without using a global variable will for sure be much of a pain.

I challenge you to notice the performance difference between all this alternatives, remembering that this will probably be used 100 times per frame and LÖVE sleeps every frame plus uses vsync in some PC's and you will probably have some more costly operations like drawing ones...

If you need a saying to understand this then "Optimization is the root of all evil" is one that is constantly said amongst programmers

[raidho36]

I did in fact said that they probably run equally since they're pretty much doing the same thing. Also hardcoding things as magic numbers everywhere is just a poor practice, specifically because it makes adjustments needlessly difficult, and in the sample I provided this is specifically avoided.

"Optimization is the root of all evil" is one that is constantly said amongst programmers

Yes, the most programmers that never had to program anything timing-sensitive like, you know, a videogame. The same people that gave Java such prominence, wholly unwarranted, which if shall I remind anyone is the core reason why there's a certain stigma attached to Android devices. It's not a very good example of a quote that anyone should go by. "What you sow, so shall you reap" is more like it. If you didn't design it to run fast, it will not. Or rather, if you make it out of pieces of code that are slow individually, it will run slow as a whole.