lua-users home
lua-l archive

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

>> THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter when a function requires it.
>> status - planning, prototyping
> I am not too fond of this. Considering that there are no explicit objects, and tables are the one-size-fits-all complex data type, I kinda like that lua syntax explicitely distinguishes between calling a function that is stored in a table (dot) and calling said function as a method. This adds magic and introduces behaviour that is not imediately clear when reading the code. As in:
> some.stuff()
> is "stuff" a method of "some" or just a function? This is immediately clear with the current syntax.

You could continue to use " some:stuff() " as a programming style

Using OOBit:

a={} = 'Lua'
a.f = method(ver) print('Name: '' '..ver) end

a.f('5.1.4')  -- works
a:f('5.1.4')  -- works too !!
a.f(a,'5.1.4') -- Fails without an error: 2 selfs. (see 1)

OPTION 1 (I like more)
f(a,'5.1.4') -- error "method requires a table call"
f('5.1.4') -- error "method requires a table call" (see 2)

OPTION 2  ( compatibility way )
f(a,'5.1.4') -- works
f('5.1.4') -- Fails without an automatic error

Perhaps an oocompatibility() function (irreversible) could select
OPTION2 ( in a LuaState basis). It could be useful to handle previous

Traditional way

  function a:g(ver) print('Name: '' '..ver) end

For compatibility with whole previous code, functions declared like g,
could maintain the traditional behavior .

Another option is to use set the OOBit of a table (perhaps with a new
keyword) to activate, in table calls, the method behavior of:

1) traditional functions:

b = new {}  -- or ooset( {} )
b = a.g

a.g('5.1.4') -- fails
a:g('5.1.4') -- works
b.g('5.1.4') -- works
b:g('5.1.4') -- works

2) All functions, including methods.


1) This could cause a compatibility problem with legacy code if you
pass a "method" as a parameter to a library that makes a call like "
table.param(table, ... ) " instead of "  param(table, ... )  ". That
would be rare, but worth mentioning.

2) Can catch an error that current implementation cannot.