15 ms·

Really? Seriously, Lua is a fine language, and doesn't need this objective-crap thrown in top of it. How to make a simple thing, more complicated. Just b/c you

• mbrubeck 17y ago
  My friend Josh is working on a big project in Lua, and part of his wishlist is a Lua-compatible language with "classical" OO (language-level classes and interfaces): http://blog.reverberate.org/2009/02/09/disappointment/ http://blog.reverberate.org/2009/02/09/disappointment/ http://blog.reverberate.org/2009/02/09/static-lua/ http://blog.reverberate.org/2009/02/09/static-lua/
  • silentbicycle 17y ago
    I don't see the point of adding classes* to Lua, but implementing points 1 and 7 (the error for undeclared vars and nonexistent fields, not the "as userdata" part) is done as an example in PiL. See strict.lua. Any variables not declared as local default to globals, and you can trap the use of globals quite easily by hooking __index and __newindex in the global table's metatable. * With a class-based system, you first write an abstract version of what you need, then create instances. With prototypes, you just create the instance, and if generalizing is worth doing (it often isn't!), you can spawn new objects based off of it. I wonder if classes themselves encourage over-abstraction. Of course, you have to use prototypes idiomatically, or they just seem like weird classes. (This is also orthogonal to static analysis.) To really take advantage of static typing, you would probably need to add support for it to the Lua VM. I don't know of any languages as lightweight as Lua with good static type systems, though - and I agree that an ML-like language as lightweight and clean as Lua could be really nice.
    • stcredzero 17y ago
      To really take advantage of static typing, you would probably need to add support for it to the Lua VM Understandable, but not entirely correct. See StrongTalk. You can have the static typing be in the parser/compiler frontend only. The programmer can get feedback about type metadata, and can use it in refactoring and ensuring program correctness. The VM has to know bupkus about that stuff. In particular Lua's VM is good enough that in most cases it's not needed for performance reasons. This makes the typing system somewhat circumventable. But the type system is usually circumventable even in a traditional static typed language. At some point, you have to count on programmers not doing stupid things. On the other side of the coin, such type systems are optional. Which means that you can have less typing for prototyping and rapid development, and more for mature code going into production and maintenance.
      • silentbicycle 17y ago
        I originally had a few lines about how it would "just" be usable for static analysis, debugging, etc. otherwise, but that would still be worthwhile. I haven't looked into StrongTalk yet though, so thanks. :)
        • stcredzero 17y ago
          Whoops, it's spelled Strongtalk. Arrgh!
• startingup 17y ago
  I agree. This would only complicate the language, without adding much of value.