Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lua Properties Design #27

Open
perbone opened this issue Sep 16, 2020 · 4 comments
Open

Lua Properties Design #27

perbone opened this issue Sep 16, 2020 · 4 comments

Comments

@perbone
Copy link
Owner

perbone commented Sep 16, 2020

The idea is to design how properties will work in Lua and Godot. A property will be a variable in the class object and will follow the definitions from the initial call for the implicit available properties method.

Following below is an excerpt for some of the the designs I have so far.

local class = require 'lua.class' -- Import the system class library
local Sprite = require 'godot.Sprite' -- Make sure to import the base class

local Main = class.extends(Sprite) -- Create the user subclass

Main:properties {
  { name = 'width', type = Types.number, default = 10 },
  { name = 'height', type = Types.number },
  { name = 'title', type = Types.string, get = 'get_title', set = 'set_title' },
  { name = 'description' }
}

function Main:ready()
  self.height = 5
end

function Main:process(delta)
  print(self.width * self.height) -- Should print 50
end

function Main:get_title()
  return 'The title is ' .. (self.title and self.title or 'undefined')
end

function Main:set_title(title)
  self.title = title
end

return Main

The description property in the code above has the default data type of string.

Please share your thoughts on this idea or show us a new idea that you come up about this topic.

-- Perbone

@zhangshiqian1214
Copy link

How about design like this

    local class = require 'lua.class'       -- Import the system class library
    local Sprite = require 'godot.Sprite'   -- Make sure to import the base class

    local Main = class(Sprite)
    function Main:ctor(...)
        self:super("ctor", ...)
        self:signal("sum_calculated",  { "sum"}, {"num1", "number"}, {"num2", "number"}}})
        self:signal("completed")
        self:signal("new_title", {"title"})
    end

    function Main:_ready()
        self.height = 5
    end

    function Main:_process(delta)
       print(self.width * self.height)     -- Should print 50
       local num1 = math.random(100)
       local num2 = math.random(100)
       local sum = num1 + num2
       emit_signal( 'sum_calculated', sum, num1, num2 )
    end

    function Main:get_title()
        return 'The title is ' .. (self.title and self.title or 'undefined')
    end

    function Main:set_title(title)
        self:super("set_title", title)
        self.title = title
    end

@perbone
Copy link
Owner Author

perbone commented Sep 16, 2020

That is interesting... I think it's possible to support both models with the same underlying API. I'll think about it.
Thanks a lot to,
-- Perbone

P.S. For future comments please try to stay in the issue topic, this one is about properties, not signals. And I know they are related! Thanks!

@perbone
Copy link
Owner Author

perbone commented Sep 17, 2020

After thinking a little bit more about this, I realise it would not work that well with the statics analysis where the parser identifies properties and signals to be use in the editor. It would be too fragile to deduct this kind of information based on code to be executed on runtime only. In my initial design this information is captured on object creation, a most stable place to do statics analysis.

@carabalonepaulo
Copy link

Main:property {
    'width', 'number',
    set = function() end,
    get = function() end
}

Main:property { 'height', 'number' }
Main:property { 'description' }

The first and second item of the array side are respectively the property name and type. Default value may be the third? Or can be included in the hash side like set/get.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants