On Mon, Jun 27, 2011 at 5:25 PM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> wrote:
> but that isn't a reason to not add them to the language itself.
A language does not grow in a healthy way by adding things for which you
cannot find a reason to omit.
I'm not surprised to hear this argument from you as I've seen you post similar garbage before. Frankly your reply is offensive and not at all constructive, rather that making such
a childish statement, in the future please give a valid argument as to why a suggestion is not a good idea and you'll get a civil response from me.
There are many very good reasons to add an API or some other standard way to cap memory usage. The obvious one being that anyone who needs to cap memory can do it by just calling the already existing API instead of reinventing the wheel or searching the internet and then copying someone else's code. While it may be obvious to you that creating a custom allocator is a potential solution, that is not at all obvious to someone who is new to Lua even if they are a highly proficient C/C++ programmer. In my opinion, the need to cap memory is such a common problem that it ought to be supported already without having to use a custom allocator or modify the Lua source code itself. Certainly you can argue that I am an idiot and my opinion is wrong, but please provide evidence and reasoning behind your statement or do not reply at all if you cannot do so.
> change the current behavior so that t[x][y][z] will just return nil
> if t[x][y] is nil and t[x][y][z] = 'abc' would set t[x][y] = {} if
> t[x][y] was nil
This is easy:
debug.setmetatable(nil,{__index=function()end})
I've seen this solution proposed before, I do read a high percentage of the posts on this list... but this does not fulfill the requirement that was stated very clearly if you had only bothered to read what I had said. It also requires access to the debug library which may not be available in many environments. If you are going to so casually dismiss my suggestions, at least propose a valid solution to the problem. Not only does t[x][y] need to return nil if t[x] is nil, but t[x][y]=z should work if t[x] is nil. Of course, I could use metatables to get this to work, but that requires writing extra code and setting the metatable every time I create a new table... isn't Lua supposed to be simple and easy to use?
Please tell me why you believe Lua has reached the perfect level of capabilities and does not need to evolve any further, and use arguments other than telling me how to do something by writing a lot of additional code. By that argument we don't need Lua at all since I can do anything with C or even assembly language already, and certainly we do not need Lua 5.2 since there is nothing in Lua 5.2 that I can't already do with Lua 5.1 either directly, with C functions, or by modifying the Lua 5.1 VM myself.
From what I understand, one of the primary design goal behind Lua is to keep the language small and easy to use, thus things such as UTF8 support, regular expressions, etc have not been added to the language. Certainly I can accept this argument, although I do not agree with it completely as it is also possible to have build options which allow these features to be removed in constrained environments. You could also argue that you do not have the time/resources to add such features, and I can certainly understand that as well. If that is the case then perhaps it is time for PUC-Rio to start accepting code contributions from others instead of maintaining Lua as a open source / closed contribution language. I am 100% sure that there are many people who read this list who would be very happy to contribute code that becomes part of the standard Lua language and there are certainly several people at least who have been around long enough that they would be able to continue to provide support for their contributions.
The point of all of this being that when proposals are offered that are small in scope and make the language easier to use the person who proposed such a feature deserves a response which is cordial and correct, not a response which is neither. For all those reading this far or those having skipped to the end, I apologize for my ranting and do not mean to pollute this list with such nonsense, but for some reason I could not let this one go without a response.
