Forum.iFiction.Ru

Ох... Полный оффтоп пошел - прошу прощения у тех, кто писал в эту тему с совсем другими целями, нежели полемика по поводу ООП... Но не ответить noname просто не могу (настолько у него своеобразный -  при этом имеющий мало общего с реальностью - взгляд на объектно-ориентированное программирование). Модераторы, секите и гнобите меня - я этого заслуживаю!

noname написал:

ASBer, видишь ли, у меня есть своё видение того, как должен быть устроен парсер

RTADS меня пока не устраивает проблемами со склонениями: я хочу, что бы мой парсер принимал команды на правильном русском языке, и выдавал ответную реакцию на правильном русском языке. в RTADS я могу добиться некорректных реакций от своего кода. и исправить это для меня так же сложно, как свой парсер написать

Добиться некорректных реакций? Или у тебя проблемы с формулировками, или у меня - с пониманием (но никак не у ТАДСа со склонениями; вернее, они есть, но сильно преувеличены). Добиться некорректной реакции кто угодно c легкостью cможет от любого языка и для любой области применения - достаточно в первой же инструкции, например, выполнить деление на ноль - вот и некорректная реакция. В свете этого прошу пояснить, что же конкретно имелось в виду.

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

noname написал:

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

А что, в RTADS - не так? Все это выполняется путем множественного наследования, например при следующем определении

Shtukovina: container, surface, item

будет одновременно контейнером (класс container), поверхностью (surface) и переносимым объектом (item). Чем тебе не свободная комбинация свойств родительских классов? (В нюансы сейчас не углубляюсь, чтобы не раздувать и без того оффтопный пост).

noname написал:

пойдём дальше:
почему бы каждому объекту не задать список свойств, связанных с каждым глаголом?

И опять-таки: что, в RTADS - не так? Да ровно так и обстоит дело - у объекта имеется метод-обработчик, отвечающий за реакцию на конкретный глагол.

noname написал:

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

По-моему, достаточно сделать для глагола один обработчик, в котором проверяются некие условия и в зависимости от их (не)выполнения выводятся различные реакции/сообщения об ошибке, не находишь?

noname написал:

допустим, создаём новый объект 'яблоко'. для начала все его свойства=0, т е задана дефолтная обработка // как правило, просто выдаёт 'стандартное' сообщение, и ничего не делает
если автор хочет, что бы его можно было съесть- делаем свойство 'съесть' объекта 'яблоко' равным 1 // т е - стандартное поедание объекта
задав ещё несколько свойств (взять, и т п - исходя из того, что с ним нужно будет делать) - автор уже добавил новый объект в игру! // ну, правда, просклонять его ещё надо
если нужно добавить ядовитый объект- без проблем: добавляем функцию съесть_2, вызываемую, если свойство 'съесть' какого-то объекта равно 2 // т е - объект ядовит
добавить новый глагол- без проблем! - для этих всех добавлений можно даже прогу написать, типа Adrift, через которую можно добавлять в квест любые объекты и реакции

вот это было бы простой и понятной парсерной платформой

Все, что ты написал выше - ровно описание того, как это делается в RTADS;).

Если ты описываешь яблоко как


Yabloko: item
;


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


Yabloko: fooditem
;


(это в случае, если тебя устраивает стандартная для этого класса реакция - исчезновение яблока из инвентаря и вывод текста "Было очень вкусно!").

Если не устраивает, можно просто переписать обработчик для глагола "есть", например, так:


Yabloko: item
Nadkusano=0
verDoEat(actor)={}
doEat(actor)={self.Nadkusano:=self.Nadkusano+1;
                      "Ты надкусываешь яблоко. Кисловато, но есть можно.";
                    }
;


Про "добавить новый глагол": непонятно, что имеется в виду - то ли определение новых глаголов для игры, не прописанных в стандартной библиотеке, то ли добавление нового глагола динамически во время игры. В подробности вдаваться сейчас не хочу - слишком обширная тема, да и пересказывать мануал - занятие неблагодарное, но и та, и другая задача средствами RTADS решается.

noname написал:

// давайте, разгромите мои бредни в пух и прах - буду рад конструктиву

Ну, не знаю, есть ли в моем потоке возмущенного сознания конструктив. Вообще (извиняюсь за переход на личности) посты noname иногда напоминают пассаж из рассказа Тэффи "Взамен политики":

– А вы что же изволите изобретать?
– Да еще наверное не знаю. Что нибудь да изобрету. Господи, мало ли еще вещей не изобретено! Ну, например, скажем, изобрету такую какую нибудь машинку, чтобы каждое утро, в положенный час, аккуратно меня будила. Покрутил с вечера ручку, а уж она сама и разбудит. А?
– Папочка, – сказала дочь, – да ведь это просто будильник.
Капитан удивился и замолчал.

Отредактировано uux (17.04.2009 21:44)

Возвращаясь к вопросу MixeratoR'а - наверное, действительно единственная менюшная платформа с ООП - это ТОМ. Любимый мною (R)TADS, конечно, позволяет писать менюшные игры, но это все-таки извращение. Рекомендую поймать ASBer'а на слове и выжать из него техподдержку в плане написания игры по максимуму;).

Отредактировано uux (19.04.2009 13:35)

noname написал:

uux, ну и причём тут ООП? ни Русский язык, ни Аристотелевская логика, ни моё больное воображение, никогда не претендовали на то, чтобы быть объектно-ориентированными.

Ладно, согласен, был неправ - слишком засмотрелся на заголовок темы. Про ООП ты действительно ни слова не говорил.