RE:Need standard kernel supported class in Lua, was: Macros and expressivity

["Grellier, Thierry" <t-grellier@...>]

In that case, I don't understand why then not returning a class table to
benefit Lua unaltered and compact syntax?

    class "Foo"
        :inherit_from( Baz )
        :readWriteField( "name", "_name" )

    function display( self ) print( self:name() ) end

    or, if you want scoping

    function Foo:display() print( self:name() ) end

Yet I think that Lua not having a standard class is in the end a
weakness
Despite academically one would enjoy defining a class system (well no
reason why this can't always the case), this is quite a show stopper.
It is a "very big loss" of time defining what everything else has and
then explaining how this prevent from reusing other tools with
confidence or taking time to explain why this class definition is better
than another one, or just this syntax is better...
They key reason Python was selected here (Lua can be used only for
configuration, but is one of several possibilities) was "there is no
class in Lua" (hear standard). All other argument for Lua weren't strong
enough:
- the speed advantage of Lua doesn't help (if we would really want speed
we wouldn't use script and Lua speed can actually be made really bad
with bad class definition to cache method lookup). 
- given the trend, embedded systems are not that resource constrained.
Imagine that embedded systems start reusing cell phone socs which are
made very cheap given volumes. And well, we are not using it in embedded
context...
- Even co-routines didn't help not selecting Python although they were a
lot more useable than generators and posix thread.
- combine this with absence of bitwise of operators...


was:
Turning to my class examples, without the sugar but with the support for
parenthesis-free passing of function arguments we get:

    class "Foo" function()

        inherit_from( Baz )

        function display( self ) print( self:name() ) end

        readWriteField( "name", "_name" )

    end

This is an improvement over:

    class "Foo" ( function()

        inherit_from( Baz )

        function display( self ) print( self:name() ) end

        readWriteField( "name", "_name" )

    end )

But still looks strange. Furthermore, "function()" is a lot more to
stick on
the end of a line than "do".

The other reason I started adding in the notion of a standard dynamic
scope
was that it avoids having a global references detector complain about
the
declaration of "display". This could actually be handled as:

    class "Foo" ( function()

        inherit_from( Baz )

        function _S:display() print( self:name() ) end

        readWriteField( "name", "_name" )

    end )

But as with the explicit function creation, the use of a magic global
variable feels odd compared to using special syntax.

(On a tangential note, it might be interesting to require special syntax
for
accessing the global environment -- e.g., global symbols would have to
be
prefixed with "$". Variables would be "local by default" except that you
would still have to declare them so essentially they would be
"undeclared by
default".)

Mark