singalen | (no subject)

Entry tags:

(no subject)

А я тут решил встроить Lua в Wesnoth. Встраивается он интересно: API нехарактерное. Вместо объектной модели вызовов, из C надо доступаться к некоему стеку, в который надо заталкивать и извлекать параметры.
Подрублю к движку доменную модель на C++ - покажу и расскажу.

Заодно обнаружил, что кроме билда на autotools там есть билд на SCons, и развивается ещё один на cmake. Я знаю, что эти тулзы - уже года три как не новость, но сейчас на cmake переходит всё больше и больше проектов.
Например, KDE собирают на cmake. Вот статья о том, как они пытались в 2006-м сначала перейти на scons, но фич не хватало, и саппорт от коммюнити был дохлый.
Хотя лично мне уровень абстракции scons нравится больше. К тому же, я время от времени корябаю что-то на пайтоне.

Autotools с их тремя версиями и жутким синтаксисом давно пора сдохнуть. Как хорошо, что это, считай, произошло.

CDT 6.0 в Ecipse 3.5 работает. Тоже отлично билдит, и даже умеет extract method/mark occurencies.

Flat | Top-Level Comments Only

Что-то недопонял что ты хочешь сделать с Луой?
Но всё равно думаю, что лучше не надо. ОО, написанный на C++ есть Squirrel. Практически, Луа + классы. Может, он подойдёт лучше?

Хочу встроить как движок ИИ в Веснот.
"ОО, написанный на C++ есть Squirrel" - wrong. Кроме изоморфизма собственно языков, есть особенности платформы.
Для Lua есть LuaJIT, он отлажен, он портируется куда угодно, у него отличная производительность, у него юзерская база.
Вот если бы он обещал, скажем, trace compiler - можно было бы подумать :)

Про встраивание в Веснот понятно. Непонятно "Подрублю к движку доменную модель на C++ - покажу и расскажу."

LuaJIT не портируется куда угодно. А про Lua можешь мне не рассказывать - сам знаю. :)
Гораздо интереснее LuaJIT MetaLua. ;)

Domain model. В смысле ddd.
MetaLua - интересно, но какая в этом польза?

Не знаю, что такое "domain model в смысле ddd". :(

Такая же как и от любого другого метапрограммирования. Сразу приходит в голову EDSL и прочее buttom-up programming. В общем, сильно помогает, если пишешь "программы, которые пишут программы, которые пишут программы..." ;)))

http://en.wikipedia.org/wiki/Domain-driven_design
Модель предметной области.

Кажется, не наш случай. К счастью. Пусть такие программы пишут на лиспе :)

То-то и оно, что самая известная реализация мультиметодов написана на ЛИСПе. ;)

Кстати, когда подрубишь к движку - _обязательно_ расскажи. С особым упором на доменную модель.
А то из википедии я ничего не понял! :)))

неплохая подборка инфы про Lua
http://www.ilovelua.narod.ru/
и про то, как на Lua "проэмулировать" ООП
http://www.ilovelua.narod.ru/about_lua.html#OOP

Неинтересно. Кажется, это всё есть в "Programming in Lua".
Вот если бы они мультиметоды написали... :-D
Но это я лучше сам опубликую :-D

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

Я прочитал, что мультиметоды требуют отвязаться от одинарной диспетчеризации на таблицах (виртуальных методов). Что резонно.
И непонятно, как вообще делать диспетчеризацию, если есть только duck typing.

Как-как? Руками.

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

function intersect(shape1, shape2)
   if shape1.type == "square" and shape2.type == "square" then
      intersect_squares(shape1, shape2)
   elseif ...
end

Но лучше сделать в таком духе:

local Intersects = {}
Intersects["square"]["square"] = intersect_squares
Intersects["square"]["circle"] = intersect_square_circle
Intersects["circle"]["circle"] = intersect_circles
Intersects["circle"]["square"] = function (c, s) intersect_square_circle(s, c) end
...
function intersect(shape1, shape2)
   local fun = Intersects[shape1.type][shape2.type]
   if fun then return fun(shape1, shape2)
   else error "Unknown shapes" end
end

И вот тут MetaLua может сильно помочь. ;)))

Для этого нужно, чтобы у объекта было свойство type. А обычно его нет :)
Есть metatable, или там __index, но по ним типы особенно не разрулишь.
В момент объявления метаметода тоже надо как-то идентифицировать тип.

Как я понимаю, никакого "канонического" ООП в Lua тоже нет. Так что правила мы можем задавать сами. Хотите мультиметоды? Следуйте нашим правилам (используйте нашу библиотеку). Ну а метапрограммирование позволяет всю эту кухню от пользователя скрыть.

Каку же скрыть-то, если типы объявлять только через нашу библиотеку?
Придумаешь пример кода?

Если я придумаю пример кода, то что останется для тебя? :)))
Проще самому всю библиотеку реализовать! :-D

Можно "регистрировать" (неявно?) пользовательские классы в библиотеке, и при этом выдавать им сгенерированный тип.
Наверняка можно ещё как-то. Надо CLOS покурить, чтобы было от чего отталкиваться.

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

Ладно, тогда я подумаю на эту тему поконкретнее. :)
Гляну на LOOP и на CLOS - напишу свой вариант. А ты расскажешь, чем он не нравится. ;)

BTW, разве в CLOS не duck typing?

defclass?

В Python объявления class Foo: тоже есть. Duck typing это не мешает.

И шо, и issubclass(Foo, Bar) сработает, если я в Bar определю все методы Foo?

Я про issubclass в Питоне ничего не знаю. Но мне казалось, что термин duck typing придумал Гвидо. Можно, конечно, в википедии посмотреть. Но мне это не кажется принципиальным.

issubclass() необходим для диспетчеризации мультиметода.
Тут надо или трусы одеть, или крестик снять.

Я, конечно, могу придумать другой механизм диспетчеризации. Сделать runtime type inference, определять, какие параметры подходят каждой реализации метода... но это решение будет хуже проблемы.

В Lua же нету даже defclass, потому что только таблицы.

Ты хочешь реализовать мультиметоды через множественную передачу? Или зачем тебе issubclass понадобился?
Мне кажется, что таким образом решится настолько общая задача, что это решение будет никому не нужно.

Но если очень хочется, то можно реализовать issubclass на том же метапрограммировании, приписывая инстансам классов подходящим образом сгенерированный тип, и проверяя его.

Множественная передача - это multiple dispatch? А это не определение ли мультиметода?

Про множественную передачу - это я вспомнил зубодробительную схему из книги Джефа Элджера про C++.

Так зачем тебе issubclass понадобилась?

Там это называлось "двойная диспетчеризация", и пример был развёрнут только по двум параметрам. Больше можно, но слишком громоздко.

issubclass - чтобы корректно реализовать твой пример. Сейчас он нарушает принцип подстановки Лисков.

У Элджера рассматривается и "удвоенная двойная диспетчеризация", и множественная - я чуть мозг не вывихнул. :)))

Т.е. ты хочешь на место параметра подставлять класс или его подкласс? Если для подкласса нет специального правила? А кто-то так вообще делает?

Ну, собственно в упомянутом LOOP есть функции class(object), instanceof(object, class), subclassof(object, class) и superclass(class). Так что можно приниматься за дело. ;)

http://en.wikipedia.org/wiki/Liskov_substitution_principle

За какое дело? Я пока остановился на Lua. Это зрелая технология.

А я что сказал? :)
(это про принцип подстановочности)

И я про Lua. LOOP = Lua Object-Oriented Programming, если что. ;)
Хорошая, кстати, библиотека.

Ты спросил: "Если для подкласса нет специального правила? А кто-то так вообще делает?"
Я ответил: все так делают, принцип Лисков - это базовый принцип ООП.

На LOOP посмотрим.

Ну, если базовый, то простой табличной диспетчеризации не получится - придётся громоздить вложенные if'ы. Впрочем, можно попробовать совместить и то, и другое.

Flat | Top-Level Comments Only