Необходим ли API над языком QSP?
Всего : 10
Возможно, оттого, что я больше программист, чем литератор, процесс написания игры на QSP в значительной степени состоит из попыток написать код игры с минимальным числом повторов и как результат, я увязаю в сложности грамотной (с точки зрения программирования) обработке происходящего в игре.
В связи с этим у меня вопрос к вам, написавшем уже не одну и не две игры: было бы легче писать игры, если бы работа с предметами, действиями, событиями и т.д. велась через работу с объектами и их свойства?
Т.е. вместо создания предмета в рюкзаке "лампа", переменной "лампа_горит", написания множества условий 'если есть предмет "лампа", то есть действия "А", "В", "С"' и прочей горы неочевидного кода - создать один раз объект: "лампа", обозначить его тип: "предмет", прописать там же все возможные действия с ним со всеми условиями, там же добавить его описание, и т.д.
Что скажете?
Неактивен
voden, если ты не уточнишь, что же ты подразумеваешь под API для QSP, то народ так и будет продолжать (как здесь, так и на форуме Куспа) либо нести чепуху, либо оборонять уже занятые рубежи (в части возможностей платформы) с девизом "Ни шагу вперёд!"
Неактивен
Nex написал:
Коверкать существующий язык, ради удобства привыкших к объектному подходу программистов, нельзя ни в коем случае. Это будет не "шаг вперед", как наивно предполагает Олегус, а огромный прыжок назад.
Так никто не говорит, что нужно что-то коверкать. Объектный подход вполне может сосуществовать с процедурным. Кому что нравится, и у кого какие задачи удобнее тем или иным подходом решать. Заметь, я не говорю "у кого на что ума хватает" — вовсе нет.
Неактивен
Кстати, изрядным подспорьем для "эмуляции" объектной системы было бы добавление в платформе возможности обработки несуществующих локаций. В этом случае куча запросов по реализации объектной модели отпадёт, как мне кажется, сразу. Точнее посылать таких просящих можно будет с более лёгкой душой.
Например, в модуле меню мне сейчас приходится называть функцию "Меню.ДобавитьПункт" и вызывать её с передачей параметра — именем "объекта", например:
Пример 1: GS 'Меню.Создать', 'МенюСундука' GS 'Меню.ДобавитьПункт', 'МенюСундука', 'Осмотреть сундук' GS 'Меню.ДобавитьПункт', 'МенюСундука', 'Открыть сундук' GS 'Меню.Вызвать', 'МенюСундука'
Было бы удобнее (и нагляднее) использовать такой код:
Пример 2: GS 'СоздатьМеню', 'МенюСундука' GS 'МенюСундука.ДобавитьПункт', 'Осмотреть сундук' GS 'МенюСундука.ДобавитьПункт', 'Открыть сундук' GS 'МенюСундука.Вызвать'
А в обработчике уже парсить имя несуществующей локации и на основе результатов что-то делать дальше.
Например, разработчик модуля ведёт список объектов, созданных данным модулем. В обработчике из имени несуществующей локации он вычленяет потенциальное имя объекта, ищет его в своём списке и (если находит) обрабатывает его должным образом, вызывая правильную функцию (т.е. всё тот же код, который приведён в примере 1).
Тут, конечно, возникают другие вопросы, например:
Поскольку каждый подобный модуль будет добавлять свой обработчик, то как прервать обработку получившейся цепочки после того, как "объект" опознан и обработан? Возвращать что-нибудь в Result? Например 0 — продолжать, не ноль — обработка завершена. И если в конце обработки платформа в Result имеет 0, то выводить "Локация не существует"…
Вроде как подобный функционал никак не коверкает существующий язык. Кому это не нужно — просто не будут это использовать.
Неактивен
Nex написал:
Вах, и это тот человек, который воюет с оффтопами.
Ничего не имею против добавления обработчика ошибок, эта возможность действительно ничего не должна "поломать".
Ну если ты думаешь, что это не относится к теме "объектов" в QSP, то тебе стоит перечитать ещё раз и форумы, и логи каналов.
Nex написал:
Заодно отладку можно сделать более функциональной, например - выводить ошибки в доп. описание, +важную информацию по состоянию, без прерывания процесса игры.
Только я бы расширил до обработки любых ошибок, а не только "несуществующая локация".
А вот это уже оффтоп, да.
Неактивен
Nex написал:
Olegus t.Gl. написал:
Так никто не говорит, что нужно что-то коверкать.
Неужели? Воден не предлагает писать библиотеки, ему, разумеется, нужно, чтобы это было встроено в QSP "как стандарт". А это уже не "добавление возможности", а перекраивание всей концепции языка.
Не нужно додумывать фразы и разъяснения за других и развивать дискуссию, исходя из неправильно сделанных выводов. Непонятно — спроси.
Коверкать — это портить (изменяя) существующее. Однако можно так ввести новые возможности в саму платформу, что и старый функционал тоже останется, причём — в неизменном виде. При этом Воден, насколько я понял, говорит, что он хотел бы стандартизированного подхода к работе с объектами (одинаковые действия реализовывались одноимёнными функциями — это реально облегчает запоминание), а не смену стандартов работы с платформой, типа "теперь игры надо писать так, а кто так не пишет — тот лох!"
Неактивен
Nex написал:
если ты думаешь, что это не относится к теме "объектов" в QSP
Конечно, не относится. Это относится только к конкретно твоей реализации, которую тебе лично "неудобно" писать без обработчика ошибок.
Ты просто возомнил, что "объекты" можно писать только твоим, 1С-образным методом. Это заблуждение.
Отношение прямое, так как это только один из вариантов (а не единственный!), который может помочь решить некоторые проблемы с реализацией псевдо-объектов в QSP без необходимости перелопачивать сильно основу платформы. Кто хочет — использует, кто не хочет — обходится стандартным функционалом. В итоге — все довольны. Пока у кого-то не начнёт получатся лучше и быстрее.
И подобный подход как раз можно "стандартизировать", что, возможно, и хочет Воден. Например, если есть список объектов, то функция, возвращающая количество этих самых объектов, должна называться "Количество" или "Размер". Если происходит обращение к описанию объекта — "Описание". Ну и тому подобное. И автор будет уже интуитивно понимать, где ему какой метод можно использовать, даже не открывая документацию.
Nex написал:
Однако можно так ввести новые возможности в саму платформу, что и старый функционал тоже останется, причём — в неизменном виде
Тут-то ты и ошибаешься.
Нет, разумеется можно всё потереть и заново переписать. Если ты иначе не умеешь, то твоя точка зрения понятна, и не стоит её развивать — здесь речь не об этом.
Неактивен
Nex написал:
Зная концепцию языка QSP, не один раз перелопатив исходный код платформы, участвуя в разработке игр на QSP на протяжении многих лет, зная как Байт относится к развитию платформы, я говорю, что это невозможно. И "ты не умеешь" здесь ни при чем, переделывать платформу, если это потребуется, буду не я, а Байт.
В данной конкретной ситуации - это невозможно, таковы обстоятельства.
Увы, но если после всего этого опыта ты продолжаешь маниакально хвататься за "развивать ничего не нужно — это всё испортит", даже не пытаясь рассуждать или приводить аргументы (нельзя и всё), почему это всё испортит, то смысла участвовать в этой дискуссии у тебя нет. То что ты годами загоняешь людей в прокрустово ложе своих собственных представлений о том, как должно всё быть, не делает тебе чести и не прибавляет веса твоим ничем не подкреплённым утверждениям.
Nex написал:
И подобный подход как раз можно "стандартизировать"
1С-объектное программирование на QSP? Ужас какой!
Не дай бог.
Что ты привязался к 1С? Тебе претят русскоязычные команды? Тогда это у тебя накопился лишний груз "программистского прошлого", а твой опыт взаимодействия с авторами гроша ломанного не стоит.
Если же ты хочешь участвовать — говори по делу, подробно и с аргументами.
Неактивен
Nex, не будем развивать оффтоп. Ты уже забуксовал — никаких новых аргументов от тебя не слышно. Давай всё же по теме и чуть более уважительно к её автору.
Неактивен
Nex написал:
Про "аргументы" я в предыдущем сообщении уже написал.
Ну если это все твои аргументы, то на этом спор и прекратим.
Будем ждать Водена с разъяснениями, что же он имел в виду под API и есть ли тут вообще связь с объектной моделью.
Неактивен