"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 лет их как понимать в вакансиях, что есть запись в трудовой книжке о трех годах, или если я фрилансю несколько лет и есть репозитории-проекты это доказывающие, то тоже считается?

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

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

ХДЕ?

В Москве.

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

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

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

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

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

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

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

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

Есть не очень значительная разница в знании мелких тонкостей языков. И неимоверно огромная разница в знании фреймворков. Питоно-программисты почти никому не нужны без 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, а сериализуется только то, что есть в таблице экземпляра

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

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

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

ну, просто у меня уже есть поле с классом, которое кладется при сериализации, а так получится что мне придется придумать надкласс

Ну, я сериализую для передачи по сети по типам: Список снарядов: { '123123' = {type = 'laser', pos = {10, 20}, vec = {.32, -.64}, len = 3}, '456456' = {type = 'bullet', pos = {10, 20}, vec = {.22, 32}, spd = 6} } На обратной стороне, фабрика вызывает создание снаряда заданного типа (класс), и указывает статы, если не существует.

да, у меня то же самое

у меня есть своя объектная библиотека с наследованием

при сериализации я отправляю таблицу объекта и имя класса

при десериализации я создаю класс по имени и заполняю свойствами

Ну, сам объект может иметь больше полей, например методы (destroy, clone, collidewith). Просто дописываешь ему метод tostring и fromstring.

методы в __index

А, да, такое норм.

Можно ещё сам класс пересылать, кстати.

стандартные свойства тоже в __index

в таблице экземпляра только свойства экземпляра