я просто уже сам окончательно запутался тобишь воткнуть верхнего автора как используемый обьект нельзя, это ж не яп { "author" : { "id" : "value", "name" : "value", "surname" : "value" }, "book" : { "title" : "value", "author" : "id", "numOfPages" : "value", "genre" : "value" } } а типа потом нужно будет вытаскивать и работать как то с ним, это мне типа к книжке значит сразу приписывать ид автора что ю потом сравнивать с авторами на сходство

да, вот как раз графкюэльный пример нашел: { "posts": { 4565633: { "author_id": 599, ... }, 4565634: { "author_id": 599, ... }, }, "autors": { 599: { "posts": [4565633,4565634] }, } }

лучше id делать ключами, чтобы потом нужного автора не искать перебором

в смысле парой конкретно указывать куда сразу идти? меня что то просто с простых вещей жесско паяет, вроде не сложно а понять не в состоянии

res = тот json выше author = res.authors[599] first_post = res.posts[author.posts[0]] как-то так

обьекты\таблицы мы получаем как таблицы? как я понял еще и с "нормальной" нумерацией с 0

две поправки по примеру моему: json не умеет числовые ключи, не луа) и глупый js сортирует как хочет, так что выдача в таком виде без порядка

забыл, json не только для js

тогда зависит от языка

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

луа зе бест для встраивания, ничего лишнего, нужен json - бери библиотеки

вся забава с json'ом - в json'е есть тип null, в луа его нет, вот и выбирай библиотеку, которая нулл реализует как тебе нравится

а свою проверку какую то черкануть никак? или заганять null как строку ну типа сложно, там же по сути главное получать передавать данные а остальное можно уже попробовать обрабатывать на месте

конечно можно, не очень и сложно самому json составлять

не очень хорошо это, потому что cjson очень быстр, а самому так быстро не выйдет

по секрету, в json'е null нафиг не нужен, от него никакого эффекта в результате

я имел в виду то как пустые таблицы в jsonе хранятся - это разные библиотеки по-своему и решают

Хе-хе, на определённых данных, неплохо работает как раз формат аналогичный json'у. authors = { {name = 'Stephen Edwin King', bdate = 1974, books = {2}}, {name = 'Douglas Noël Adams', bdate = 1952, books = {1}} } books = { {title = 'The Hitchhiker’s Guide to the Galaxy', date = 1979, author = 2}, {title = 'It', date = 1990, author = 1} } Чот такое. Тут в качестве id-ключа выступает номер в параллельной группе. Выгрузка списка книг конкретного автора выглядит примерно так: getBooksByAuthor(name) local author for i, v in ipairs(authors) do if v.name == name then author = v end end if not author then return nil, 'not found' end local booklist = {} for i, v in ipairs(author.books) do table.insert(booklist, books[v]) end return booklist, #booklist end Для унификации всего этого счастья и автодополнения, нужны всякие первичные-вторичные ключи, язык запросов (или методы взаимодействия), механизмы поддержания целостности данных и прочая фигня. Но зачем, если есть sql/nosql?

я имел в виду то как пустые таблицы в jsonе хранятся - это разные библиотеки по-своему и решают

Как стандарт - пустая таблица ([]/{}). И это правильно, потому что с "другой стороны" ждут список/таблицу, и пытаются его обработать, даже если он пуст.

как кому нравится

Ниет, тут стандарты :3 В противном случае, json был бы опасен.

мне этот подход не нравится, надо думать как сериализатору сказать - это пустой массив, или это пустой хеш

по этому в моей реализации пустой массив или хеш - это его отсутствие

Не надо думать. field = {}, перед тем как мы вообще начали парсить содержимое таблицы. В общем, ты не прав, товарищ. Стандарты есть стандарты, или это уже не json.

да парсить то другое, я про превращение пустой таблицы в json строку

http://www.json.org/json-ru.html Почитай ECMA, тут валяется. А, пустая таблица превращается в скобки. t = {yo = {}, foo = {1, 2, 3}, bar = {a = 10, b = 20}} -> "{"yo":[], "foo":[1, 2, 3], "bar":{"a":10,"b":20}}" Пустая таблица = пустой список. Инфа сотка. Обрабатываются одинаково.

нененене

какой это пустой список?

"yo":[]

и если я жду {} на другой стороне?

Пофигу, они идентичны в плане обработки. И в стандарте json - это пустой список.

таки да! [].что_угодно = null

Дыа. И это правильно. А если вместо [] - ничего нет, то сама попытка сделать null.что_угодно вызовет ошибку.

Кстати, нафига велосипед изобретаешь? Из интереса?

А зачем для Lua данные хранить в json?

велосипед потому что cjson дает {} в качестве пустого массива, а у меня в js логике были методы массивные - result.reduce(...) и вываливалась ошибка типов, вот и написал велосипед

зачем - делаю лучший в мире веб фреймворк, вот прямо без преувеличений, а там json на каждом шагу

.... скоро точно пойдут вакансии джысон погромистов.

лучше бы луа вакансии начали идти

Хе-хе, работаю луа-программистом :3

Тоже.

Кто на митап ходил — IPONWEB разослали информацию о вакансии.

Если кому интересно: https://hh.ru/vacancy/20000625

Требуемый опыт: 3–6 лет дальше смотреть не стал

Это не чёткие рамки же.

На докладе сказали, что собеседуют всех.

ну от 3 до 6 да не четкие, не написали же что конкретно 3,2 =)

хотя странный подход, зачем писать так если принимаете тех кто проидет собеседование

Может, имеют в виду не только коммерческий опыт.

Дык есть много вакансий. Вру, немного. Я отхватил почти единственную. Мутю бекенд.

а эти 3-6 лет их как понимать в вакансиях, что есть запись в трудовой книжке о трех годах, или если я фрилансю несколько лет и есть репозитории-проекты это доказывающие, то тоже считается?

Нормальные работодатели воспринимают портфолио как несколько лет работы

Добро пожаловать в чат pro.lua, //⁠YOGURT! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

Добро пожаловать в чат pro.lua, Wes! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

Хе-хе, работаю луа-программистом :3

ХДЕ?

В Москве.

я сколько видел вакансий, так либо эмбедщики, либо надо ещё и перл знать, либо ещё чего

ну, не считая клаудфлари, taobao и т.п.

Ну, так подфартило. Но я и приходил не нулевиком.

у нас на Lua пишут в Тарантуле и в игровом направлении. И в Москв, и в Воронеже.

а вилки зп какие? Ну, чтобы потроллить знакомых PHP-макак :)

когда я пару лет видел вакансию - там хотели какого-то Шиву на Lua за 100k :)

Если человек программист, то нет разницы на каком языке он пишет. Отличие наверное только на перегретых языках - жава, мобайл

по кр мере среди ЯП с динамической типизацией - питон там, или взять пхп, перл, луа - разницы большой нет

ERROR: S client not available

Есть не очень значительная разница в знании мелких тонкостей языков. И неимоверно огромная разница в знании фреймворков. Питоно-программисты почти никому не нужны без django, а javascript - без querry/react/node и ещё кучи либ/фреймворков. И знания их тонкостей. Это разные вселенные, в которых котируются очень разные архитектуры.

тоже правда

Прочитай эту штуку: http://russian.joelonsoftware.com/Articles/LordPalmerston.html Самая суть: "Неудержимые абстракции ведут к тому, что мы живем с очень резкой кривой обучения: вы можете выучить 90% того, что вы используете каждый день за неделю обучения. Но что бы разобраться в остальных 10% займет еще пару лет. Это то, чем по настоящему опытные программисты отличаются от людей, которые говорят ”не важно, что вы хотите, что бы я сделал, я могу открыть книгу и научиться делать это”. Если вы строите команду, это нормально иметь множество менее опытных программистов для написания больших участков кода с использованием обобщенных инструментов, но команда не может начать работать, если у вас нет нескольких по настоящему опытных членов команды для выполнения действительно сложной работы." "Вы можете думать, что основу программирования составляют ваши превосходные C++ знания 90%, а различные API это только 10%-ый пушок, в котором вы сможете разобраться за несколько недель. Этим людям я скромно подсказываю: времена изменились. Соотношение изменилось на противоположное."

хорошо сказано.

Товарищ, который пишет эти заметки - весьма крут. И мы пользуемся его stackowerflow и trello ну раз в неделю - это точно. Тема не устарела пятнадцать лет спустя, и не устареет до тех пор, пока сама суть программирования не изменится. Там есть ещё много что, достойное прочтения.

черт что то дырки в памяти случаются на ровном месте, работаешь над чем то, день\два отдохнул и по новой приходится тратить некое время что б войти в колею и все вспомнить где что зачем

Это нормально. http://russian.joelonsoftware.com/Articles/HumanTaskSwitchesConsider.html

Человеческий мозг ограничен небольшим набором абстракций, которые можно держать в голове. Записывай и комментируй.

Дырки в памяти легко решался __mode: 'kv' вроде так

Попробуй повесить метатаблицу на мозги :3

Вам смешно, а я уже ловил себя на мысли, что неосознанно придумываю метатаблицы для различных предметов. Metatable головного мозга.

Вопрос один мучает: кто придумал подчеркивания двойные? зачем? у этого есть история или эзотерический смысл?

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

Когда ты делаешь упрощённый класс, ты пишешь что-то такое: Class = {} Class.__index = Class function Class:new(...) return setmetatable({...}, self ) function Class:__add(v) ... end function Class:__call(v) ... end function Class:__newindex(k, v) ... end function Class:foo(...) self.bar = {...} end Шоб прям в классе перегружать операторы над объектами и всем таким. Имена такие - чтобы легко запоминались, чтобы было сразу понятно что это МЕТА(метод/индекс/объект), и да, чтобы не мешали всему остальному. В луях, "приватные" поля часто делают с подчёркиванием в начале. Понятное дело что менее приватными они не становятся, но зато всем ясно что это служебная штука и менять её не стоит. Ну там, obj = { field_n = 10 _serviceField = 'servicedata', } Что-то вроде соглашения. Так же как использование "_" в качестве хранилища для ненужной переменной. i в цикле не используется - значит будет _. for _, v in ipairs(table) do v.n = v.n + 1 end

Спасибо, все логично и продуманно

ipairs без надобности использовать не стоит, не знаю как в jit, а в ваниле он чуть медленнее

А потом ты упарываешься и переопределяешь иттератор

В полтора раза, да. Но ты делаешь преждевременную оптимизацию. ipairs объективно удобнее обычного цикла. Заменять ipairs на for i = 1, #t do local v = t[i] ... end будешь только в шибко нагруженных местах.

ipairs лучше использовать если у тебя в таблице "дыры" или индекс не числовой

На правах холивара: без 10 преждевременных оптимизаций появляется electron на десктопе

Поправка: не числовые индексы - pairs. Разница там приличная. Поправка 2: Electron появляется не только без преждевременных, но и без обыкновенных оптимизаций, и на неподходящей архитектуре.

тоже верно :)

https://blog.toggl.com/wp-content/uploads/2017/04/toggl-how-to-kill-the-dragon-with-9-programming-languages.jpg

вопрос ума: Имеется система классов предметов для инвентаря, есть класс еды. У еды из разновидности есть только дефолтные значения, поведение еды не меняется. Как лучше сделать разновидность еды - разными наследниками или одним generic классом и фабрикой, которая заполняет его свойствами ?

Один класс и фабрика, которая заполняет данные - уникальный id + набор статов/параметров из конфига еды. Если там есть эффекты - в том же конфиге набор методов. С оружием - та же фигня.

да, это звучит лучше чем тонна наследников, у которых прописаны только свойства

правда конструкция получается неоднородной, тоесть одни предметы создаются одним путем, другие - другим

хотя можно сделать тип предмета параметром в конструкторе

Ну, основной класс, который содержит кучу методов, типа: "eat", применяющий баффы при съедании, событийные методы (got/lost/бла-бла) и всё такое, которые дёргают метод соответствующей еды, если есть. При создании образца, создаётся объект, который применяет тыкнутые фабрикой методы при съедании и применении баффов, укладывании в инвентарь, извлечением из него, взятием в руку и всем таким.

блин, моя сериализация к этом не готова.. дефолтные значения лежат в __index, а сериализуется только то, что есть в таблице экземпляра

так получется что экземпляр будет хранить свойства

а если не сериализовать это, то придется придумывать подкласс и сериализовать его, и при десериализации обратно задавать значения... это как-то страшновато