lua-users home
lua-l archive

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

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) = name

class B extends A
	function B(name)

	function toString()
		return name

b = new B('me')

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

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

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

-- 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})

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 ?