100% agreed.
Lua doesn't need a standard 'class' system. There is the danger of locking people into it (a mild danger) but there is also the danger of bringing in things that are not necessary to many people.
If something is going to change in this direction, it will probably be one of those clever devices one of the Three Creators sometimes devise to solve a thousand problems with some simple concept, a handful of code and almost no overhead ;-).
I couldn't agree more (with both e-mails).
OOP is just too messy, too complex a problem to fit this definition. It should be a *use recommendation*, not a language construct. And s such, should come in several flavors.
Whether OOP is messy or not, I just think it is completely unnecessary for most applications. In most scenarios where Lua is used as an extension language for applications written in, say, C++, you want the extension mechanism to be as simple as possible. If you want to design big fancy OOP systems, you do it in C++ and then expose your system to Lua.
Some people have argued they could see no killer feature in Lua that could justify not using Python. Well, for me it works the opposite way. None of Python's features are attractive enough to justify the extra burden and complexity of embedding Python instead of Lua.
Lua's current design is very good for the purpose it was created for, being an "extensible extension language".
-- Thiago
On Jan 14, 2008 7:29 PM, Javier Guerra <
javier@guerrag.com> wrote:
my two cents:
- most 'quick & dirty' programs doesn't need OOP
- the obj:mth() syntactic sugar trivially handles encapsulation and polymorphism
- most OOP simple (and not so simple!) designs doesn't need inheritance.
- if you need a full inheritance class system, there are several to
pick from. some of them really sophisticated.
- no matter how a class system is implemented, if it uses the
obj:mth() sugar for method calls, it can interoperate with other
systems.
so.... why the fuss?
--
Javier
--
Luís Eduardo Jason Santos
