Closed Jazzelhawk closed 8 years ago
Reasons for inclusion?
Libraries and Types should be documented, so I'm sort of on the fence regarding their need to be iterated. Especially when the iteration method requires custom invokation and not the standard - Users would have to learn a specific way for table iteration for Libraries and Types. Is this better than not including any at all?
The Libraries and Types are documented yes, but if a user wants to wrap functions or anything else then there is no other way to get them automatically. Users would not have to learn anything if they don't want to. It wouldn't be much to learn anyway as the custom iterator function is used exactly the same as the pairs function. Another method would be to have a function return a list of all the keys in a given type. I don't see how having this functionality could be worse than not having it. There is no downside to being able to iterate over them.
I was going to argue, why not just modify pairs or ipairs to do conditional parsing depending on if we give it a library or not. BUT. That would be horribly inefficient, as there is probably a 99% use-case for standard Lua use rather than our tables. So adding a special function makes sense I guess, and it DOES have incredible functionality for users within game. Having had to checkout your branch myself for that purpose, I kind of realised it's needed. Good Job. Merged.
Otherwise there is no other way to get field names and values from libraries or types since their type definitions use a proxy table.