Ну это того.. Наследованием? Объявляем абстрактный класс сущности, имеющей, допустим, координаты и размеры, ну, и заодно пустые методы update/draw, чтобы было. Пишем к нему метод move. Наследуем от него всё остальное!

Вот тебе пример проекта с такими сущностями: https://bitbucket.org/MainTomato/tank-o-box/src/61410a4ea6bf8bbd61c0a3b9bfdbbb2f585b100b/data/entity.lua?at=master&fileviewer=file-view-default Только без метода move, но он тут частично подразумевается через applyCollision : ) Тут же, кстати, неплохой сет моих либ.

у тебя есть movable объект. Есть функция move которая принимает move(Movable, Destination)

зачем наследование?

не надо переусложнять)

(пока не надо)

но я тебя понял

Ну типа вызвать метод объекта проще, чем искать какую-то конкретную функцию. А если у тебя будет ещё пять объектов, которые можно будет двигать, но чуть по другому, допустим, им при движении нужно будет ещё что-то делать, шаги считать или двигать составные части? Что, делать пять разных функций: "moveObjFoo", "moveObjBar"?

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

ООП с наследованием для чайников от Снусмумрика:

Ну, а в ООП - foo = {} foo.__index = foo function foo:new(x, y) local o = {x = x, y = y} return setmetatable(o, self) end bar = setmetatable({parent = foo}, {__index = foo}) bar.__index = bar function bar:new(x, y, w, h) local o = self.parent:new(x, y) o.w, o.h = w, h return setmetatable(o, self) end foobar = setmetatable({parent = bar}, {__index = bar}) foobar.__index = foobar function foobar:new(x, y, w, h, z, v) local o = self.parent:new(x, y, w, h) o.z, o.v = z, v return setmetatable(o, self) end

Проследи, что вызывается в функции o = self.parent:new(x, y, w, h, z, v) Там дёргаются функции new начиная от foo:new до foobar:new. Можешь обозвать не parent а super. Это более питоноподобно и типа "традиционное" название батьки, а ля "суперкласс".

Методы и ключи у потомков вызываются по мере поиска. Нашли в объекте? Вызвали или выдали. Не нашли? Поискали у класса. Нашли? Выдали. Нет? Поискали у суперкласса. И т.д, дальше сам разберёшься, тут всё по изичу.

Ну, в результате удобно делать интерфейсы. Допустим, прописали функцию draw и у суперкласса и у дочернего класса. Объекты суперкласса будут пользоваться методом draw суперкласса, а дочернего - дочернего. Таким образом, можно не париться с виртуальными классами, а хуярить сразу реальные. Если внезапно нужен перезаписанный метод суперкласса - можно вызывать как self.parent.method(self, a, b, c). Родитель родителя, соответственно, self.parent.parent. Просто как три копейки, давай осваивай )))

Спасибо

Ребят, интерпритатор lua подскажите топовый

luajit,

?

Ну ясен хрен. P.S. Сообщения можно редактировать.

Ребят, можно писать чисто на луа? Есть пакетники?

Luarocks. Можно писать чисто на lua, но если тебе нужно что-то специфические (функции ядра, например) - пишешь header и гоняешь любую сишную библиотеку напрямую. Как альтернатива - ставишь dynasm и катаешь на ассемблере на lua. https://luapower.com/dynasm Эти фичи как раз предоставляет luajit.

Luarocks. Можно писать чисто на lua, но если тебе нужно что-то специфические (функции ядра, например) - пишешь header и гоняешь любую сишную библиотеку напрямую. Как альтернатива - ставишь dynasm и катаешь на ассемблере на lua. https://luapower.com/dynasm Эти фичи как раз предоставляет luajit.

Ты сделал мой день

Ой, как будто писать на асме - это так странно ))))

Очень просто, была бы документация к ним. По документации пишется header, и всё, вот тебе ffi.C.foobar.

Я руками все писал когда в клон хса встраивал интерпритатор

Ты про ffi, ты прав. И кстати, если есть исходники сишной библиотеки - хедер можно выдрать в полуавтоматическом режиме.

интерпрЕтатор

Интерпритатор, от слова "прикольная *штука*!" )) Корень - "при", остальное - приставки, суффиксы и окончания.

дратутите, а есть тут господа которые вебсокеты на openresty терминировали?

@Snusmumriken

Вебсокеты не лазал (( Только обычные сокеты.

Вебсокеты не лазал (( Только обычные сокеты.

жыаль, в обычные я и сам могу

Я с удовольствием в вебсокеты лазал! С рестями - одно удовольствие! Какие вопросы?

около года голову ломал с ними, потом нашел патч: https://github.com/slact/ngx_lua_ipc патч от создателя nchan - значит, очень умный человек писал, на деле оно действительно работает это вместо редиса и прочих mq - позволяет воркерам внутри nginx передавать друг другу сообщения, то что надо для ws

Я с удовольствием в вебсокеты лазал! С рестями - одно удовольствие! Какие вопросы?

благодравствую белый господин а вот сюда не смотрели? https://github.com/openresty/lua-resty-websocket

т.к. у меня собрано все в рамках RnD (гавно и палки), я сделал так, что на запрос запускается бинарничек и результат отдается в сокет (бираник поприетарный от яндекса, расколупать его нельзя) делаю это через sockexec, типа в контейнере с openresty слушает sockexec демон, который через unixsocket получает запросы на запуск программ, запускает и отдает результат при этом воркер не зависает, т.к. поллит unix socket на ответ асинхронно

если мамка узнает - по заднице надает, да

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

от бинарника и sockexec я к сожалению вближайшее время отказаться не могу

Рома я тогда чуток попозже вас помучаю, если буду концептуально не понимать

т.к. у меня собрано все в рамках RnD (гавно и палки), я сделал так, что на запрос запускается бинарничек и результат отдается в сокет (бираник поприетарный от яндекса, расколупать его нельзя) делаю это через sockexec, типа в контейнере с openresty слушает sockexec демон, который через unixsocket получает запросы на запуск программ, запускает и отдает результат при этом воркер не зависает, т.к. поллит unix socket на ответ асинхронно

ахтунг

Я холю-лелею тестовый экспериментальный фреймворк рести, там вебсокеты и прочее, суть сказанного про socketexec и мамку уловить не просто, могу ссылки на вебсокетный код скинуть

а чего бы тебе его просто на гх не запилить? :)

bebebe, во избежание флуда можешь в личку

я на всякий случай поясню, как это у меня работает, что бы вы понимали что за гавно и палки запускается docker container в нем запускается демон sockexec https://github.com/jprjr/lua-resty-exec который слушает /tmp/sockexec.sock (unix socket) запускается openresty к openresty приходит клиент на /endpoint с запросом я пишу в этот сокет (/tmp/sockexec) shell команду типа echo запрос_пользователя | yandex_program жду асинхронно её окончания (не блоча воркер) программа возвращает результат, я запихиваю её в сокет клиенту

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

Оки, так какие проблемы с openresty/lua-resty-websocket?

1) подключить юзера через ws 2) принять запрос 2) запустить shell 3) результат запостить обратно юзеру через его соединение

наверное, дело в том, что запустить shell команду и отправить ответ пользователю надо в отдельном треде, ngx.thread.spawn который, звучит просто

go

тебе же пишут go

JavaScript

C++ для браузера

JavaScript

этого не слушай

Работы много

да вы что наркоманы чтоле?

Ну он не адекватен, я согласен

+1 за питон

go

не животе прошлым

https://habrahabr.ru/post/274099/

Ахаха, не факт что примут

Точнее сто пудов не примут

Дома объясню

И да, я ебал так писать

Уасилий впал в рейдж

опасно

Чувак, ты опять фигнёй страдаешь? : (

Твой рейдж-мод тут никому не нужен, чувак-Чувак ((

Да. Лучше оба

А лучше знать все языки

Пх'нглуи мглв наф'х Ктулху Р'льех вгхнагл ф'хтагн.

Ещё Brainfuck и Whitespace можно изучить.

Я имел ввиду lisp или c#

Rust

В расте не меньше всяких приколюшек чем в С++

haskell уже советовали?

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

А никто не заставляет использовать весь функционал С++. Как сказал создатель С++ Б.Страуструп, для того, чтобы писать хорошие программы на С++ не обязательно знать о С++ всё.

торч по-моему живое доказательство, что очень даже все серъезно