Re: Cryptic OOP syntax

[Adrian Sietsma <adrian_groups@...>]

André de Leiradella wrote:

> > What do you mean by "putting OOP in the core"?
>
> Having native support to OOP in Lua:
>
> class A
> 	function A(name)
> 		self.name = name
> 	end
> end
>
> class B extends A
> 	function B(name)
> 		super(name)
> 	end
>
> 	function toString()
> 		return name
> 	end
> end
>
> b = new B('me')
> print(b.toString())

why put it in the core ? that's what the library mechanism is all about!

i have a basic library in my head (and on scraps of paper)
2 new userdatum : class and object.
it's very similar to the system in PIL, but wrapped in userdatum.

-- define a class
account = class("account",{balance=0, repay = somefunc})

-- add a method
account.withdraw = function(thisself,amount) -- this or self or xxx
  thisself.balance = thisself.balance + amount
end

-- lock class from further modification
account._close() -- class def'n is closed - no more new members allowed
end

-- create an object
myaccount = account.object({balance=1000}) -- an object
myaccount:withdraw(500)

-- a subclass
specialaccount = account.class("special",{withdraw = newfunc} )

-- overloaded constructor
local o = specialaccount.object
specialaccount.object = function(self, balance,limit)
  -- validate params
  return o(self, {whatever})
end

myspecial = specialaccount.object(550,2000)

and because they are userdata,
type(account) == "account_class"
type(myaccount) == "account_object"
type(specialaccount) == "special_class"
type(myspecial) == "special_object"

myaccount.class() = an account class object
myaccount.super() = nil
specialaccount.super() = an account class obj
specialaccount.super("account") - look for any ancestor


 the only thing i can't see how to do is easily protect members of 
class table data :
x.classdata = y -- i can direct that to instance table
x.classdata.field -- once you return the classdata table, its members 
are vulnerable. there are ways to protect it, but it's not built-in

all this can be done using simple lua primitives ie metatables,
and all you would need to say in yr code is
require "luaclass"

NO core mods reqd.

>Those who are against OOP, as I was once against packages, should take
>some time to think if the features they use are needed by other users.
>Having OOP doesn't mean you'll have to use it.

and having an OOP library/package means :
1/ we can choose not to use it.
2/ it can be developed and tested on the standard (and beautifully 
stable) core.
3/ it can be upgraded/enhanced/modified without changing the core.


ps this was an interesting design exercise, but i doubt i'll ever write 
the code - it's not necessary for my lua usages.

pps we use lua for
1/ config management in c++ apps
2/ dynamic menus & help ditto
3/ full-blown lua app (with some c library funcs)
the c library funcs are mainly a modified lines() that detects and 
returns \f for page boundaries, and some os utilities.
(a lua app that uses 100% cpu for 20 seconds on a 2ghz machine, is 
working hard - i could have used std lines() & string.gsub, but it's in 
the inner loop)

let's face it : you can build and use lua without the table, string and 
math libraries - and you want to build-in OOP to the core ?

Adrian