Я только не представляю ка креализовать приватные поля пока что

Upvalue в замыканиях, но в целом — соглашение между джентльменами.

Называем особые методы/свойства через _private_method, и в них никто не лазает, потому что есть шанс сломать : )

Это прост быстрее всего. Upvalue — отжирают лишнее место и требуют генерации функций для работы с ними для каждого объекта в отдельности, вместо того чтобы дёргать классовые. Сделать "общие" приватные поля можно в локальной табличке в файле с классом, это настолько же быстро как и дёрганье методов класса, но оно общее для всех объектов.

хех, ясн

Как в сишном модуле зареквайрить луашный модуль локально?

Ничоси у тебя запросы : )
А что ты хочешь?

lua_getglobal(L,  "require");
lua_pushstring(L, "cjson"); // например, cjson
lua_call(L, 1, 1);
int ref = lua_ref(L, -1);

Вот у тебя теперь ссылка на табличку-модуль. Когда нужно — вставляешь её в стек, извлекаешь нужную функцию и вызываешь.
Запихивание обратно в стек через
lua_rawgeti(L, LUA_REGISTRYINDEX, ref);

В сишке нет такого понятия как "локально", мы можем разве что не модифицируя глобалспейс луа-стейта вытащить ссылку.

Таки зачем нужно?

Не понял вопроса. Вот допустим хочу внутри сишного модуля распарсить json и при этом не хочется засорять глобальное пространство имён у юзера этого модуля.

Жуть какая : )

Не эффективнее ли предоставить пользователю выбор json-библиотеки, и просто принимать табличку? Прироста в скорости парсинга json'а ты не заметишь, зато вводишь явную и очень жёсткую зависимость.

Ну это я как пример написал.

Тем не менее, сишные модули которые зависят от луёвых — это не очень хорошо, да и структура Lua => C ломается :<

Ну там, я в своей стимовой либе делал вызов луёвых функций, типа:
lua_rawgeti(L, LUA_REGISTRYINDEX, callback_table);
lua_getfield(L, -1, "userfunc");


lua_call(L, 0, 0);

Но там сама библиотека инициализирует и выдаёт юзеру в пользование табличку callback_table, и запоминает ссылку на неё. Пользователь заносит в неё функции, и дёргает сишную "вызвать колбеки", которая дёргает луёвые. Это конечно тоже не очень хорошо, и по хорошему надо бы выгружать в луа список колбеков, которые были вызваны с предыдущего дёрганья, но у меня не было желания делать сто тысяч миллиардов типов колбеков, там уже особенности самой steamworks. То есть, структура как бы не очень приятная, но хоть нет зависимостей от внешних модулей.

Ещё один лайфхак: на луёвой стороне гораздо проще написать код, проверяющий ошибки. На сишке это будет миллиард бессмысленных и беспощадных действий перелопачивания стека, в котором без поллитры потом не разберёшься. Поэтому используй луёвые либы с луями, для своего же блага : )

lua_call(L, 0, 0);

По примеру кода не очень ясно. Таблица типа такой

cs = {["onSomeEvent"] = user_added_func}

?

Типа такой:

local steam = require'luasteam'

-- таблица steam.callback запомнена внутри сишной либы
function steam.callback.onFriendMessage(friend, msg)
 print("Got " .. msg .. " from " .. friend:getName())
end

while true do
 -- Эта штука вызовет функцию (если есть)
 -- когда наступит событие
 steam.eventPump()
end

Если ты пробовал ловку, то схема такая же, только без луёвого фронтенда (там луа сначала получает события, а потом дёргает луёвые же функции если есть).

Ну да, после правки — похоже на то.

Кстати, через int ref = lua_ref(L, -1); можно запоминать ссылки на функции, например. То есть, у тебя в сишном модуле функция "setJsonDecoder", которая принимает из луа функцию, запоминает, а потом вызывает при нужде. Но тут всё равно проблемы обработки тех же ошибок типа "невалидный json".

То есть, тут могут быть ссылки на любые ссылочные типы (коих примерно четыре).

А если я всё-таки хочу повесить вторую функцию на событие причем из другого места в коде?