Any interest in adding "skeleton" code to the README?

[hahawoo]

Sometimes I want to do something simple and small with love-api, and I had been wishing I could copy and paste some base code so I could change it to do I wanted instead of having to look at the table structure and write code to loop through everything.

So maybe it would be useful to add something like this to the README?

Here is what I have now: (not thoroughly tested!)

local api = require('love-api.love_api')

-- api.version

local function loopArgumentsOrReturns(arguments, argumentOrReturn, function_, variant, module_, moduleOrTypeOrCallback, prefix)
    for _, argument in ipairs(arguments or {}) do
        -- argument.type
        -- argument.name
        -- argument.description
        -- argument.default (optional)

        for _, flag in ipairs(argument.table or {}) do
            -- flag.type
            -- flag.name
            -- flag.description
            -- flag.default (optional)
        end
    end
end

local function loopFunctions(functions, module_, moduleOrTypeOrCallback, prefix)
    for _, function_ in ipairs(functions or {}) do
        -- function_.name
        -- function_.description

        for _, variant in ipairs(function_.variants) do
            loopArgumentsOrReturns(variant.arguments, 'argument', function_, variant, module_, moduleOrTypeOrCallback, prefix)
            loopArgumentsOrReturns(variant.returns, 'return', function_, variant, module_, moduleOrTypeOrCallback, prefix)
        end
    end
end

local function loopTypes(types, module_)
    for _, type_ in ipairs(types or {}) do
        -- type_.name
        -- type_.description
        -- type_.parenttype

        for _, constructor in ipairs(type_.constructors or {}) do
            -- constructor
        end

        for _, supertype in ipairs(type_.supertypes or {}) do
            -- supertype
        end

        for _, subtype in ipairs(type_.subtypes or {}) do
            -- subtype
        end

        loopFunctions(type_.functions, type_, 'type', type_.name..':')
    end
end

loopFunctions(api.functions, nil, 'module', 'love.')
loopFunctions(api.callbacks, nil, 'callback', 'love.')
loopTypes(api.types, nil)

for _, module_ in ipairs(api.modules) do
    -- module_.name
    -- module_.description

    loopFunctions(module_.functions, module_, 'module', 'love.'..module_.name..'.')
    loopTypes(module_.types, module_)

    for _, enum in ipairs(module_.enums or {}) do
        -- enum.name
        -- enum.description

        for _, constant in ipairs(enum.constants or {}) do
            -- constant.name
            -- constant.description
        end
    end
end

So if I wanted to, for example, print out the functions which return a single boolean and have one or more arguments, I can copy and paste the code above and just write this in the variant loop:

if variant.returns and #variant.returns == 1 and variant.returns[1].type == 'boolean' and variant.arguments then
    print(prefix..function_.name)
    break
end

[rm-code]

How about turning this into a more complete module which offers callbacks the user can hook into?

[hahawoo]

That could be cool. I kind of feel like this issue is somewhat redundant now due to the auto-generated fields in love-api-experiments, because that makes it quite a bit easier to loop through whatever one wants to loop through, but I would think that a module with callbacks or functions could work too, maybe even better than auto-generating fields, but I haven't really thought about it.

[hahawoo]

I've added extra.lua to the main repo now, so I don't think skeleton code would be as useful now.