2016-09-08 1 views
1

LDOC будет счастливо документировать функцию какИспользование LDOC к документу таблицу функций

--- Foo function 
-- does a foo 
function foo(param1, param2) 
end 

Тем не менее, то, что я хотел бы сделать, это документ таблицу указателей на функции.

например.

--- bar.lua --- 
bar = { 
    foo = function(a, b, c) 
    end 
} 

return bar 

--- foo.lua --- 
local bar = require "bar" 

fooapi { 
    foo = bar.foo 
} 

Я хотел бы документировать это с точки зрения fooapi, как это экспортируется API через сокет, и я хотел бы, чтобы скрыть, где он реализован специально. Он должен появиться по отношению к fooapi, и я не хочу видеть никаких упоминаний о bar.lua или bar.foo на выходе.

Так что если я помещаю комментарии после строки foo = bar.foo и перед таблицей fooapi, то итоговая документация отображает ее как просто обычное поле таблицы, а не как функцию.

Есть ли способ отменить это поведение, так что ldoc будет производить вывод, например function fooapi.foo with parameters a,b,c?

Я ожидаю рассказать о параметрах, которые не отображаются, и каким-то образом переопределить его тип, чтобы функция с ее именем переопределялась, чтобы включить вложенность в таблицу, а не просто обычное поле таблицы? Обратите внимание, что вложенность функций может пройти несколько уровней в открытом API.

Я открыт для реструктурирования кода при необходимости. Или даже переключение на другой или более гибкий инструмент. На самом деле, я не возражаю, если он не вытащит какую-либо информацию из кода lua, а просто выдает код полностью из специальных комментариев в коде.

ответ

1

Используйте явные теги, и вы в порядке!

--- Function that Foos. 
-- Does the foo things of fooapi. 
-- @function fooapi.foo 
-- 
-- @tparam boolean a AAAAAAAAAAAAAAAAAAAAAAAAA. 
-- @tparam number b bBbBbB. 
-- @tparam string c Lorem ipsum sit dolor amet. 
+0

Спасибо, я позже обнаружил это после многогония вокруг и проб и ошибок. Изначально он не форматировался слишком хорошо. – Matt

Смежные вопросы