lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Using performance as a measure on how to dictate the design of semantics in a higher language sounds utterly foolish imo.
Also, your own arguments seem to undermine themselves.. You don't want something that can "easily become a bottleneck", yet you want a 
de-facto standard, so does that mean you decide what is reasonably fast or?
I don't understand why people keep comparing lua with python or tcl or anything else, they're not the same thing, for a number of reasons.. The only common denominator is that they're languages and they're interpreted, but so what.. You're starting to sound like lua isn't compatible with itself, because it's not like python.. If python fits, use it, if lua fits, use it, but what could possibly be the point of adjusting lua to be more like python?
The fact that lua is NOT python is what attracts me to it, and I'd probably stick to the current version of lua for all time if it started changing into the next cool kid on the block, with a million "non-programmer" dictating what it should and should not do. 





Grellier, Thierry wrote:

I'm not complaining about lack of class syntax, but about profusion of
class syntaxes which furthermore make unclear which inheritance models
are used.

When quickly doing yet another class model, I realized that caching
methods can impact a lot script speed. Cleverer caching of class method
was improving the speed of my script more than directly using luaJIT.
That is metatable accesses can easily become a bottleneck with cascading
index. 
Loop is not close to be even a de facto standard (who uses it? tolua?
swig? ...). 
I'd like having a clearly specified class model, well supported not to
kill performances, and very likely to be largely adopted by third part
tools. I would bear that this class model has "limitations" (well for
example I would neither require public/private scopes, nor that if A
inherit from B and C and that B.c and C.c exists they shall be
different). Python class model looks a good base (technically and
socially).
But it can be really interesting to investigate how dynamic one would 
like to be because dynamicity/caching compromise is hard to find unless
the script kernel can extend the design burdens. 
It doesn't mean to remove the existing low level mechanism so that
anybody can still play with his beloved OO model to experiment or to
maintain existing code base. 
And I don't believe this would bloat the Lua VM code much more than
adding competing byte code for class models for those using classes. It
can probably be a configurable option for those not using it. What is
lua_conf intended for? Btw I'm surprised it doesn't include a flag to
remove parser.

I wish I could have a quick survey on how many man.weeks were spent in
companies (like adobe, and other) to build and maintain diverging object
models.

Quoting another mail (don't want to multiple post)

"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. "

That is why in the end we embed both... which I dislike because it means
that all new efforts are going to python side, and Lua is bound to
configuration (and well with very small syntax advantage compared to
python, especially with overriding __attr__ so that it may disappear, so
that it may be dropped out while I tend to think that besides class it
is better using Lua).

Quoting Lua website:

"Lua is simple and powerful
        ^^^^^^
A fundamental concept in the design of Lua is to provide meta-mechanisms
for implementing features, instead of providing a host of features
directly in the language. For example, although Lua is not a pure
object-oriented language, it does provide meta-mechanisms for
implementing classes and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
inheritance. Lua's meta-mechanisms bring an economy of concepts and keep
the language small, while allowing the semantics to be extended in
unconventional ways."

It sounds very contradictory to me. Associating meta-mechanism to
simplicity shall make a lot people running away. I would recommend
splitting "simple" and "powerful" items! And put simple at top of list
(with mentionning grammar size, keywords number, tables, scalability of
learning, used by non programmers).

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Ben
Sent: Monday, January 14, 2008 10:05 PM
To: Lua list
Subject: Re: Need standard kernel supported class in Lua,was: Macros and
expressivity

That's why LOOP exists.  Just send people on over there, and it's
cool.  It's not like the mechanisms are already there.  Considering
all the hoops you have to jump through in other languages, and also
considering the "syntax weirdity" of Lua already, compared a C-like
language, what's a couple parentheses in your class definitions?

And isn't LOOP maintained by Tecgraf?  That seems the closest you can
get to official endorsement.  It's a good system, it works, so why do
people keep complaining about a lack of class syntax?  Or is it just
not that well-known?

Cheers,
Ben