lua-users home
lua-l archive

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

On 01/03/17 03:50 AM, Dirk Laurie wrote:
2017-03-01 3:10 GMT+02:00 Soni L. <>:

So, Lua has very limited OOP:

object:method() --> object.method(object)

But, there are other forms of OOP which are useful:


These could be added to Lua as a new syntax sugar, the `:.` syntax:


I believe Lua would benefit from this. Sure, you can just keep a reference
to the object in object.system/object.trait, but then you can't dynamically
add new arbitrary systems/traits:

object.trait = sometraitimpl
object.trait:method() -- wait, why are you not modifying my `object`?

object.system = somesystem
object.system:method() -- ??? you're supposed to modify `object` D:

object.system.ref = anotherobject -- brokenpatching at its finest

And this is why I think it's a good idea.

This could also support any level of nesting:

a.b.c:d.e.f.g() --> do local c = a.b.c; c.d.e.f.g(c) end -- note how `a.b.c`
is only evaluated once
Quick standard questionnaire, marks from 0 to 10, 5=neutral,

1. Clarity of proposal?
2. New idea?
3. Do opportunities for using it arise often?
4. Will it improve clarity of coding?
5. Efficiency?
6. Attractiveness of implementation?

My ratings:

10, 0 (the OP himself claimed to have proposed this before April 2016 [1]),
  8, 10, 5, 2 (prefer the way suggested in [2]).

Cloud Wu has pointed out the start of the previous thread; my references
also come from there.

That time, only the three of us endorsed the idea. Maybe its time has
now come.


I mean, do you want arguments about the order the arguments should show up in? Because there are just as many arguments for

x:y:z() -> x.y.z(x,x.y)

as there are for:

x:y:z() -> x.y.z(x.y,x)

Here's how the latter is better:

local x = {}

x.y = {}

function x.y:z(obj)
  assert(self == x.y)

x:y:z() --> In your variant, we get assertion failed,
        --> With reverse order, the assertion passes.

Your variant would probably be bad for composition.

Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.