An improvement for when you refactor

[theoriginalbit]

When you're going through and refactoring, I suggest that on any object functions that are not getters of properties, or return any form of value, to return itself, in your case this.

Implementing this doesn't change anything for you, it just adds some other options for developers by allowing them to use the method chaining pattern. An example of method chaining in Lua can be found here.

[Gvin]

Interesting suggestion. If this may be useful for some users, we will implement this.

[theoriginalbit]

Also here is another suggestion.

The above code was the result of some discussions that I had with Symmetryc about getting function calls on Objects to be a little nicer. I'd made a helper function that cleaned the args which was very useful for my purposes, and when discussing with Symmetryc he came up with the solution that I've gone and commented and added to pastebin. It is a very handy snippet as it allows for the following function calls

--[[
Assume that Supplies.new returns a table with a function "output" which when invoked
outputs some value from the supplies object
--]]
local supp = Supplies.new()

--[[
Using normal invoking methods
--]]

-- this should be fairly familiar Lua OO syntax
supp:output()

-- we can however use "dot" notation, but we need to supply the "self"
supp.output(supp)

--[[
Using the code snippet provided
--]]

-- still the same, familiar Lua OO syntax
supp:output()

-- however, this is where the code makes it better
supp.output()
-- it should also be noted though, that this is also supported
supp.output(supp)

as you can see, it allows for people of any coding habits and/or skills to use it. Especially when quite a lot of new Lua programmers are unfamiliar with the colon notation, and find it quite difficult to understand.

[Gvin]

But you can allready do this using the LongOS class writing notation because we don't use self variable value and use this instead.
This shoud also work with functions that have some parameters.

[theoriginalbit]

hmmm yeh I thought that I hadn't explained that well enough.

I used self as a reference to the objects itself, commonly also known as this in other languages.

Ok lets take an example from on of your programs.....this one LongOS/Utilities/BiriPaint/BiriPaint.exec will work nicely...

Here is a snippet of current code (normal Lua OO invocation with colon notation)

local function run()
        local application = Classes.Application.Application('BiriPaint', false, true);

        local biriPaintWindow = BiriPaintWindow(application, launcherString);
        application:Run(biriPaintWindow);
end

System:Try(run);

where syntax is Instance:Method(Args)

By using the changes that I've proposed (using Symmetryc's solution), the code could remain defined in the way above.

But it would also allow for developers to do this (normal Lua OO invocation with dot notation)

local function run()
        local application = Classes.Application.Application('BiriPaint', false, true);

        local biriPaintWindow = BiriPaintWindow(application, launcherString);
        application.Run(Run, biriPaintWindow);
end

System.Try(System, run);

where syntax is Class.Method(Instance, Args)

or also this (conventional OO invocation found in languages such as Java and C# with dot notation)

local function run()
        local application = Classes.Application.Application('BiriPaint', false, true);

        local biriPaintWindow = BiriPaintWindow(application, launcherString);
        application.Run(biriPaintWindow);
end

System.Try(run);

where syntax is Instance.Method(Args)

[Gvin]

Oh, I think I've understood what you were saying!
Hmm... But I don't see any possibility to do this with methods with arguments except for manual checks like this:

SomeClass = Class(function(this)
  function someMethodImplementation(a, b, c)
    return a + b*c;
  end

  function this.SomeMethod(arg1, arg2, arg3, arg4)
    if (arg4 == nil) then -- instance.SomeMethod(a, b, c) call
      return someMethodImplementation(arg2, arg3, arg4);
    end
    -- instance.SomeMethod(instance, a, b, c) or instance:SomeMethod(a, b, c) call
    return someMethodImplementation(arg2, arg3, arg4); 
  end
end)

But this is too complicated solution. Maybe you have some more simple?

[theoriginalbit]

ahh see this is where the genius nature of Symmetrycs solution comes in. If you add the definition to Class it will do the logic you have there for you.

The way it works is through use of __newindex whenever a new value is added to the object (I added in a check for only functions) it will convert it into a table with the __call method. This means that when the table is called it is able to check the first argument and see if it is the self/this variable, if it is absent from the call it all add it in, otherwise it just makes the call. This means that all you need to do is this (using snippet from LongOS/Classes/ApplicationClasses/Application.lua as the example)

Classes.Application.Application = Class(Object, function(this, _applicationName, _isUnique, _shutdownWhenNoWindows)
    Object.init(this, 'Application');

    function this:AddWindow(_window)
        windowsManager:AddWindow(_window);
    end

why it means you have to change nothing is because when you're adding the AddWindow function to this the code should step in and make the AddWindow function this "special" table that then calls the function.

[Gvin]

Excuse me but I don't see any changes in the Application class part that you showed. Can you point on it please?

[theoriginalbit]

That's the point. With the change I proposed you wouldn't have to change any of your existing code! But it opens up far more options on syntax for other developers.

[Gvin]

Oh, sorry! I've red the first link that you'd added. I'll try to understand how to include it to our objects model. Thanks for suggestion and explanations!

[theoriginalbit]

Yeh the example there was specifically aimed at the implementation someone else was doing and were trying to tell me that it was not possible to do what I said was possible. I just couldn't be bothered adapting it for you too, I figured it's commented heavily enough that you should be able to interpret and understand :)
You should definitely add the implementation into the Class constructor, that way all objects automatically inherit the change again without (hopefully) the need to modify any other source.

[Gvin]

Yes, I understand. I'll try to include this into LongOS'es Class function. And I agree with your opinion that such possibility to call functions in dot style will be great.
We'll implement this feature as soon as we have some free time.

[theoriginalbit]

Ok one slight improvement to the code. It shouldn't be needed, but its a just incase.

local obj = setmetatable({}, {
  __newindex = function(self, key, value)
  if type(value) == "function" then
    local func = setmetatable({}, {
      __call = function(_, ...)
        if rawequal(self, ({...})[1]) then
          return value(...)
        end
        return value(self, ...)
      end;
    })
    rawset(self, key, func)
  else
    rawset(self, key, value)
  end
end;})

The difference is self == ({...})[1] has been replaced with rawequal(self, ({...})[1]). The improvement that this makes is, if the object defines the __eq metamethod it will be ignored and it will be compared against the "raw" table, not with how it defines it should be compared against. Without this change it could mean that it does not realise the self/this argument was included, and include it again.

Hope this makes sense :)

[Gvin]

We will use this code while implementing this feature, thanks! It's poor that we don't know native Lua methods well enough, sometimes they can greatly shorten our code.

[theoriginalbit]

Definitely. There is a lot that can be done in Lua that most people don't know about. Even I don't know everything that can be done.
But yes there's a lot. Just take a look at this. There is quite a lot of minor, but good improvements that I've made in that PR.