АвторСообщение
хитрый латышский койот




Сообщение: 290
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 18.06.08 14:51. Заголовок: AkUrq2


AkUrq 2.12 beta 8
Потихоньку пишется новая акурка2, основанная на идее Sfeli и содержащая не малую долю его кода. Возможности пока довольно скромные, но это вопрос времени.
требует только IE5 (Windows 98+)

Что мы имеем:
 цитата:
Операторы:
;комментарий
:(локация)
p (текст без кавычек)
pln (текст без кавычек)
goto (локация)
proc (локация)
btn (локация),(описание)
(оператор)&(оператор)
cls
instr (переменная)=(текст без кавычек)
(переменная)=(значение)
if (условие) then (оператор) [else (оператор)]
inv+ [число,]предмет
inv- [число,]предмет
invkill [предмет]
perkill
play (имя_файла)[.wav]
input (переменная)
end
_ (продолжение предыдущей строки)
(<= >= <> > < = - + * / ==)

Системные метки:
:Сommon[_номер]
:use_(предмет)[_действие]

Конструкции:
#/$
##(код символа)$
#%(имя переменной)$
#(имя переменной)$

Системные переменные:
previous_loc
current_loc
last_btn_caption
common
music
count_(метка)
rnd[число]
inv_(предмет)



Краткое описание языка (Выборочно использовалась помощь от Корвина) Скрытый текст



очень короткий FAQ:
 цитата:
В1: Тут слишком мало возможностей для моих извращённых идей :) где синусы, вычисление корня, тысячи картинок, xbtn, и вообще где первая акурка? (привет Суд :)
О1: Думаю первая акурка дорабатываться больше не будет. Новые операторы в квотерое появятся со временем, но не так как они появлялись в первой акурке: операторы будут появляться только после того как их синтаксис утвердят большенство метров, к которым я отношу: Евгения, Сфели, Виктора, Корвина.
Уважаемый Борщевский разумеется тоже метр, но поскольку он ненавидит урку, я боюсь его спрашивать :)

В2: Где инвентарь? Месяц найти не могу уже. (привет Хлом :)
О2: Клавиши I и F6 открывают инвентарь.

В3: Как теперь закрыть инвентарь? (привет Гор )
О3: Теми же клавишами.

В4: Как закрыть текущий квест и начать новый?
О4: F2 выводит в меню.

В5: Что можно настроить в ини файле?
О5: Можно изменить шрифт (Goraph) и включить/отключить управление кнопками на цифрах. Если результат вас не устроит, а как было вы не запомнили х) то удалите ини файл



Ну и выражаю благодарность Sfeli который написал добрую половину функций. Их легко вычислить - если чтото в квотерое работает без проблем - это писал Сфели) Если глючит - то Акела)

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

Колокола сегодня звонят особенно громко... Спасибо: 0 
Профиль Цитата Ответить
Ответов - 73 , стр: 1 2 3 4 All [только новые]


постоянный участник


Сообщение: 11
Зарегистрирован: 27.08.08
ссылка на сообщение  Отправлено: 13.10.08 07:29. Заголовок: Картинки 2-я акурка ..


Вам мо квешн плиз обана:
Картинки 2-я акурка поддерживает?

Так сложно ответить?
Да / Нет / Не понял вопроса

Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 114
Зарегистрирован: 03.07.07
ссылка на сообщение  Отправлено: 13.10.08 09:46. Заголовок: Можно скачать и пров..


Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник


Сообщение: 13
Зарегистрирован: 27.08.08
ссылка на сообщение  Отправлено: 13.10.08 11:01. Заголовок: Ну, у меня не получи..


Nex пишет:

 цитата:
Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.


А здесь проверял?
http://urq.plut.info/soft
Если хочешь пришлю 2-ю.

Но у меня не получилось применить к 2-й версии акурки ни один из картинковых методов 1-ой...
А списке операторов в самом верхнем посте вобще ничего такого нет.
Наверное всё-таки 2-я идёт без картинок. Не успелось...

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 192
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 14.10.08 18:46. Заголовок: hi пишет: Вам мо к..


hi пишет:

 цитата:

Вам мо квешн плиз обана:
Картинки 2-я акурка поддерживает?

Так сложно ответить?
Да / Нет / Не понял вопроса


лично я ничего про картинки во 2-й акурке ничего не знаю.
а про саму эту 2-ю акурку узнал только на днях-
тогда же и сообщение в эту тему написал.

просто сядь и напиши квест на URQ Спасибо: 0 
Профиль Цитата Ответить
администратор


Сообщение: 285
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 18.10.08 01:27. Заголовок: Nex пишет: Можно ск..


Nex пишет:

 цитата:
Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.

Обновил ссылки в закрепленном посте "urq_dos, Akurka, текущие версии".

Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 1
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 12:23. Заголовок: xbtn локация_процеду..



 цитата:
xbtn локация_процедуры, локация_перехода, название_кнопки

идеально!



Бред.

чем это лучче конструкции в стандартной УРКе:

btn локация_процедуры, название_кнопки
end

:локация_процедуры
goto локация_перехода
end
????

Гениальное изобретение велосипеда, в котором руль приколочен прям к колесу, для удобства
Ну, то есть, нафига придумывать команду, вызывающую последовательно две (три, насколько) локаций, если это преспокойно решается стандартными методами языка?

Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода.

Либо как сейчас в АкУРКе, (хотя точно не помню место для указания фигурных скобок): xBtn {переменная=значение}, Локация, Кнопка (), чтобы потом переменную обработать в локации. Причем достаточно только такой, жесткой конструкции (одна_переменная=одно_значение), а далее можно творить чудеса. Например, передать в переменной целый список значений (и разбить его с помощью token), или с помощью #$ передать кусок кода.

либо что то вроде

xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально
end

:Локация [Параметр]
Параметр = Параметр+Параметр.... и т.д.
end

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

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник


Сообщение: 463
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 10.12.08 15:38. Заголовок: xBtn Локация, Кнопка..



 цитата:
xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр]



Номер не пройдет, так как по синтаксису языка URQL только в последнем параметре оператора может быть несколько запятых. Название кнопки должно быть последним, следовательно, только:

xbtn локация перехода,{параметр(ы)},название кнопки, в котором могут быть запятые

Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 2
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 16:23. Заголовок: ну да, ну да. Второй..


ну да, ну да.
Второй вариант это конечно уже не URQL, а более другой язык :)

Однако, вопрос о том, КАКИМ быть xBtn, кажется, по прежнему открыт? То что БЫТЬ должен - это однозначно, так как Btn, как простого перехода, явно не хватает. Однако xBtn в текущем варианте АкУРКи 1: xBtn {Произвольный_код}, Локация, Название кнопки действительно выглядит не по УРКовски.
Но: кто сказал, что ОБЯЗАТЕЛЬНО нужен _произвольный код_? Поверьте, вполне достаточно определить значение какой либо переменной, а там уже творчески подключать мозги и делать с ней (переменной) все что угодно.

Например, так:

xBtn_VAR - системная переменная, устанавливаемая при нажатии кнопки xBtn.

синтаксис xBtn : xBtn Значение, Локация_Перехода, Название кнопки //где Значение (или указывать здесь переменную?) как раз и устанавливается в xBtn_VAR.

Пример

:question
pln 2х2=?
xBtn 3, Answer, Три
xBtn 4, Answer, Четыре
xBtn До фига, Answer, Пять
btn NoAnswer, Не знаю
end

:NoAnswer
pln Я не знаю
end

:Answer
pln Мой ответ #xBtn_VAR$
p Это
if xBtn_VAR = 4 then p правильный else p неправильный
pln ответ
end

Сие более по УРКовски - дешево и сердито. Естественно, это черновой вариант

ЗЫ. Подумалось, что уже сейчас можно реализовывать _что-то вроде_ этого, ибо доступна переменная LastButtonCaption, однако это не совсемь есть гут, потому что Caption у Button относится уже к внешним элементам квеста и не очень хорошо приспособлена для внутрикодовых нужд.

ЗЗЫ
Не. все таки, если быть совсе точным, то синтиксис должен быть таким:
xBtn Вычисляемое_Выражение, Локация_Перехода, Название кнопки

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 116
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 10.12.08 17:54. Заголовок: :Answer pln Мой отве..


:Answer 
pln Мой ответ #xBtn_VAR$
p Это
if xBtn_VAR = 4 then p правильный else p неправильный
pln ответ
end


Фигню ты написал. Кнопок может быть переменное количество, отдельные кнопки могут определяться в proc-ах и локации-счетчике. И как следить за этим зоопарком чтобы вычислить нужную кнопку? Самой правильной xbtn будет xbtn вообще без локации. Только название и список операторов. А переход можно сделать и с помощью goto. Правда тогда начинается гимор с системными переменными, но можно отслеживать goto внутри xbtn...

Тон. Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 3
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 18:06. Заголовок: ghoest пишет: Фигню..


fireton пишет:

 цитата:
Фигню ты написал



НЕА.

Сие как раз задумывалось для ДИНАМИЧЕСКОЙ генерации кнопок. Поверьте, ОДНОЙ ПЕРЕМЕННОЙ запросто хватит, для того, чтобы обработать все возможные излишества :). Честно-честно. Приведенный пример, конечно не показатель, но поверьте, мне приходилось с СУЩЕСТВУЮЩИМ xBtn обходиться всего-навсего одним оператором в фигурных скобках {переменная=значение}
До этого можно дойти чисто абстрактно, без приведения примеров. Введение даже единственной ПЕРЕМЕННОЙ в xBtn УЖЕ убирает жесткую статичность, присущую указанию метки перехода в обычном Btn, и этого достаточно(!) ДОСТАТОЧНО - в том смысле, конечно, что можно и огороду нагородить с более сложными конструкциями, что (возможно) будет и несколько удобнее, но уже не так принципиально.
В принципе, самый правильный xBtn возможен и без локации ВООБЩЕ, с одной только переменной :-D (точнее, нужна предопределенная локация типа Common) - но тут уже да, будет пахнуть извращениями

ЗЫ

 цитата:
И как следить за этим зоопарком чтобы вычислить нужную кнопку?



Я так думаю - раз уж мы ГДЕ-ТО вставляем кнопку, то именно там-то мы ее и обозначим. опять же - ОДНОЙ переменной. Ибо (опять же, абстрактно) - ОДНА кнопка = ОДНО событие, пусть даже следствием этого события будет изменение миллиона переменных и выполнение миллиона строк кода:)

Важен принцип - переменная, в отличие от метки, НЕ СТАТИЧНА, она не определяется (как метка) при написании кода, она может изменяться - а это главное.


 цитата:
Только название и список операторов. А переход можно сделать и с помощью goto


И все это внутри фигурных скобок? Хммда... Будет весело смотреть на такой код...

Вообще, конечно, если бы изначально в URQL был бы реализован такой принцип - то есть изначально btn выполнял бы список операторов, а не goto-переход, то это да, такой подход являлся более правильным, тут я согласен. Но URQL сейчас именно такой, какой он уже есть. Я всего лишь предложил НАИБОЛЕЕ МИНИМАЛИСТСКИЙ способ решения проблемы ограниченности Btn, согласующийся с уже существующей идеологией языка.

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 250
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 11.12.08 20:37. Заголовок: ghoest пишет: Вообщ..


ghoest пишет:

 цитата:
Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода.


это один из вариантов

 цитата:
xbtn локация_процедуры, локация_перехода, название_кнопки

идеально!


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

 цитата:
чем это лучче конструкции в стандартной УРКе:

btn локация_процедуры, название_кнопки
end

:локация_процедуры
goto локация_перехода
end
????


а вот этим:

 цитата:
xbtn #%локация_процедуры_ПАРАМЕТР$, #%локация_перехода_ГЛАГОЛ$, #% составное_название_кнопки$


т е ДО перехода передаются значения аргументов через соотв переменные (арг1, арг2, арг3, ... ) в соотв процедуре. ПОСЛЕ выполнения процедуры выполняем переход на локацию- обработчик. в случае 6-ти глаголов и 20-ти предметов при такой организации достаточно всего 6-ть локаций-обработчиков, обрабатывающих переданные аргументы, а не 120.

т е, как ты верно заметил, потребность в xbtn возникла из-за потребности в передаче параметров. НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным. не вижу никакого смысла специально ограничивать себя ТОЛЬКО передачей параметров. предложенная конструкция поможет решить и насущные и будущие проблемы, и даёт дополнительные, ещё неисследованные возможности.

p.s.
поясню различие ещё раз:

 цитата:
чем это лучче конструкции в стандартной УРКе:

btn локация_процедуры, название_кнопки
end

:локация_процедуры
goto локация_перехода
end
????


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

DosURQ- рулез! Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 4
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 11.12.08 22:49. Заголовок: noname пишет: НО вв..


noname пишет:

 цитата:
НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным.



Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. Если же под [локация_процедуры] имеется в виду обычная URQL-овская метка (пусть и вызываемая как бы через proc), то ничего не меняется.

Но сделать такую новую локацию-процедуру - это более жестокое изменение URQL (Кстати, в первом посте я и предлагал что то вроде (гипотетически) возможности описывать метку с возможность опционального указания у нее ПАРАМЕТРА, то есть метка становится как бы процедурой. Извращение еще то, конечно, но весь URQL весьма похож на извращение (не бить - это добрая шутка)



Поясню смысл моего xBtn c переменной. Существующий механизм Btn предполагает в описании кнопки указание жестко и заранее известной метки, уже прописанной в код. То есть тут затруднено использование динамически создаваемых кнопок, плюс к тому, для того чтобы различать нажатие разных кнопок, необходимо указание в разных операторах btn разных меток.

xBtn в моем варианте позволяет при указании одной и той же метки в разных операторах xBtn все же различать их, как раз путем установления значения переменной. И этого уже хватит для того чтобы построить обработку этих различий В ОДНОЙ локации
Вариант же с подвешиванием на Btn (или xBtn) целого списка операторов, вообще каких то действий - принципиально БОЛЕЕ ПРАВИЛЬНЫЙ, но URQL изначально не пошел по этому пути, и теперь уже трудно что то сделать без принципиального изменения языка.

Теперь конкретно, как передать ПАРАМЕТР+ГЛАГОЛ в моем примере:
(Динамически создаваемая кнопка) (не уверен насчет корректности оператора конкатенации строк, но пусть будет пока так)
Instr РАЗДЕЛИТЕЛЬ = #$ [пробел или запятая или еще какой нить разделитель]
Параметр1, Параметр2 - ранее рассчитанные выраженрия
If <условие> then instr ПАРАМЕТР = Параметр1 + РАЗДЕЛИТЕЛЬ+ Параметр2 & xBtn ПАРАМЕТР, ОБРАБОТЧИК, Название кнопки


Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 5
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 11.12.08 23:14. Заголовок: ghoest пишет: в про..


noname пишет:

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



Блин . Я все пытаюсь додолбиться, и чувствую, что просто плохо объясняю... Дизлексия блин...

В общем, как бы коротко....

На Btn должен висеть КОНЕЧНО же обработчик событий, где можно делать все что угодно. Но он НЕ ВИСИТ. И не будет висеть, по крайней мере в рамках концепции современного URQL. В URQL нет процедур, а есть только куски кода, обозначенные метками.

Вариант, когда в xBtn запихивается кусок кода - безусловно РАБОЧИЙ вариант, но просто очень неудобно запихнуть сколько нибудь значительный набор операторов в часть строки, заключенную в фигурные скобки.

Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки.

В моем же варианте xBtn реально позволяет при указании одной и той же метки-обработчика в разных xBtn разграничить эти разные xBtn разными переменными, и выполнить РАЗНЫЕ (в зависимости от значения переменных) варианты кода в ОДНОЙ локации-обработчике.



Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 6
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 12.12.08 02:42. Заголовок: Проще один раз показ..


--

Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 7
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 12.12.08 02:42. Заголовок: Проще один раз показ..


БОЖИЙ СУД :)

Проще один раз показать, чем нудно описывать.

Вот вам пример кода, ИМИТИРУЮЩИЙ конструкцию xBtn ВЫРАЖЕНИЕ, Локация_Обработчик, Название кнопки. Написан с использованием ТЕКУЩЕГО варианта xBtn, в AkURQ 1.28pre6

Кнопок может быть произвольное количество. Локация обработчик - одна.
С использованием моего варианта xBtn следующая строка:
xBtn Answer,{xBtnVAR=#I$},Answer N #I$
поменялась бы на:
xBtn #I$, Answer, Answer N #I$

------------------------------
:Start
pln enetr quantity of buttons
input Max

I=0

:CycleBegin
I=I+1
Array#I$=rnd
xBtn Answer,{xBtnVAR=#I$},Answer N #I$
if I < Max Then Goto CycleBegin
end

:Answer
pln It's a #Array#xBtnVAR$$
btn Start, Again
end
---------------------------
Описание - код генерит массив заданного пользователем размера, заполняет его случайными числами и формирует необходимое число кнопок, по нажатию на которую сообщается число, находящееся в массиве под выбранным (кнопкой) номером

Не представляю, как записать подобный алгоритм с использованием конструкции

xBtn Локация_Процедуры, Локация_Перехода, Название кнопки.

Предлагаю
1. Записать мой алгоритм с использованием конструкции xBtn Локация_Процедуры, Локация_Перехода, Название кнопки.
2. составить какой нить алгоритм с использованием этой конструкции, который было бы НЕВОЗМОЖНО решить моим методом

Для имитации, наверно, можно использовать следующую конструкцию с нынешним xBtn: xBtn Локация_Перехода, {proc Локация_Процедуры}, Название кнопки )

Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 251
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:07. Заголовок: ghoest пишет: Да, е..


ghoest пишет:

 цитата:
Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас.


ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем:
1) переход, аналогичный переходу по urq- овской команде proc на локацию локация_процедуры
2) выполняем всё что там автор понаписал, включая переходы на другие локации и любые другие хитрости до первого end - аналогично урковскому proc
3) встретив end выполняем переход на локация_перехода аналогично урковскому обычному баттону.
4) вот и всё. просто и хорошо.

p.s.
осталось ответить на два возражения:
1)

 цитата:
Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки


и
2) - последний пост ghoest. щазз попробую объяснить...

DosURQ- рулез! Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 252
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:22. Заголовок: итак, отвечаю на воз..


итак, отвечаю на возражение первое:

не знаю, было ли для ghoest существование в urq proc новостью, но вот фразы о том, что в кахих-то urq-шных командах чего-то ЖЁСТКО указывается не соответствуют действительности однозначно. рекомендую перечитать учебник по urq под редакцией Korwin-а, особенно про #такие$ и #%вот_такие$ вставки. возможно, это сразу снимет все вопросы и разногласия.

в урке возможна такая конструкция:

 цитата:
:#%переменная_1$
pln urq рулит!
btn #%переменная_2$, жми сюда, неверный
end


где в текстовых переменных переменная_1 и переменная_2 указаны соотв имена локаций. никто специально такую конструкцию не придумывал- в урке многое возможно просто исходя из логики языка.

возможно, я просто не понял суть твоего возражения. тогда- поясни. ИМХО это как раз тот случай, когда добавляя в кнопку название ещё всего одной локации получаем на одну бесконечность возможностей больше. делать xxbtn с бОльшим числом параметров уже будет незачем.

DosURQ- рулез! Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 253
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:41. Заголовок: отвечаю на возражени..


отвечаю на возражение второе:

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

твоя задумка xbtn тоже неплоха, но заведомо тесна. не вижу смысла заранее ограничивать авторов в средствах.

с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено.

твоим методом, т е с помощью xbtn, реализованного в соответствии с твоим предложением ИМХО возможно реализовать любой алгоритм, который можно реализовать с помощью xbtn сделанным по другим принципам, НО в некоторых случаях это будет гемор страшный. вот например, любой массив можно впихнуть в одномерный, НО представь, что ты пишешь игру, которая начинается в центре мира, а затем может постепенно дописываться во все стороны (вполне разумный вариант!). делаем координаты первой локации (0,0,0) на всякий случай (вдруг мы потом ещё подвал или башню где-нить поставим). и растим тихонечко мир во все стороны -> в одни стороны с "+" координатами, в противоположные- с "-". впихнуть всё это в одномерный массив ВОЗМОЖНО, но геморно. и это далеко не единственный случай (бывает нужно ещё списки предметов в карманах персонажей хранить, а для предметов- списки свойств). так же и с твоим xbtn всё возможно, но можно составить случай, когда это будет геморно.

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

DosURQ- рулез! Спасибо: 0 
Профиль Цитата Ответить
постоянный участник




Сообщение: 117
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 13.12.08 14:30. Заголовок: А хотите так: :лока..


А хотите так:
 
:локация
...
btn кноплок(10, 15), Вот такая вот кнопень
end

...

:кноплок
if (кноплок_пар1 = 10) then ...
...


Можно реализовать. Довольно нетрудно.

Тон. Спасибо: 0 
Профиль Цитата Ответить



Сообщение: 8
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 19:48. Заголовок: noname пишет: ёперн..


noname пишет:

 цитата:
ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем:



Еперный бабай! А Я ЧТО ПЫТАЮСЬ СКАЗАТЬ? Вот вы сами и сказали о том, что конструкция xBtn Локация1, Локация2, Кнопка практически ЭКВИВАЛЕНТНА комбинации из стандартных Btn и Proc (Да, я знаю и что такое proc, и что такое #$ - удивительно блин.)

Насчет #$ и ЖЕСТКОСТИ. Согласен, #$ позволяет делать вообще все что угодно. И у вас в коде, благодаря #$, могут появиться команды, которых вы сами никогда не писали. Но у вас НИКОГДА не появится МЕТКА, которую вы заранее, ручками, нее вбили в тело кода. Вот именно то обстоятельство, что любой оператор, имеющий в качестве своих операндов ИМЯ МЕТКИ, обязан обращаться к конечному набору заранее определенных меток, я и называю жесткостью.
В моем формате xBtn есть имя метки - указание на локацию-обработчик - и это ЖЕСТКИЙ, ИНВАРИАНТНЫЙ* ОПЕРАНД, но там же присутствует и выражение, значение которого передается в переменную, а значение может при обработке кода оказаться любым - и это ВАРИАНТНЫЙ ОПЕРАНД. В защищаемом же вам формате xBtn- два ИНВАРИАНТНЫХ операнда и ни одного вариативного. Именно поэтому он менее функционален и не эквивалентен моему.

*инвариант - программный объект, не изменяющийся в процессе выполнения. В данном случае я имею в виду, что операнд ссылается на такой инвариант - метку

Поясню на примере (noname):

 цитата:
:#%переменная_1$
pln urq рулит!
btn #%переменная_2$, жми сюда, неверный
end


Насчет #%Переменная_2$ - здесь, конечно же, к моменту нажатия на кнопку мы можем получить РАЗНЫЕ значения выражения #Переменная_2% и соответственно перейти на различные метки - но эти значения ВСЕГДА должны соответствовать какой либо ЗАРАНЕЕ определенной метке, иначе возникнет ошибка.
А вот насчет возможности указания метки в виде :#%Переменная_1$ не уверен (ни в AkURQ, ни в DOS_URQ эта хрень не работает ;), но если это и можно, то мы здесь имеем фактически одну и ту же метку с переменным именем. Поясните на каком нибудь рабочем примере практический смысл необходимости в переменном имени метки. Разумеется, этот пример не должен сколь-нибудь простым способом реализовываться БЕЗ переменного имени


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


ХА-ХА! Я утверждаю ровно обратное - тесна задумка с ВАШИМ вариантом. Уж точно теснее моей, а соответственно, и нынешнего xBtn {}

 цитата:

с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено.


НЕ БУДЕТ! - посмотрите мой код в БОЖИЕМ СУДЕ и сделайте такой же


Кстати, все, описанное ниже - действительно, описывает невероятный геморрой, с которым столкнется кодер, если вместо существующего xBtn {} будет иметь только xBtn Лока, лока, Кнопа. C моим же xBtn он столкнется только с необходимостью конкатенировать n-ное количество необходимых к передаче параметров в один и последующему разбору его снова на n-номе количество.


По пунктам. Формат оператора xBtn, используемый сейчас в AkURQ, с указанием произвольных операторов в фигурных скобках - отличный оператор по функционалу, но неудобный.
Раз уж возникают мысли сменить формат - хорошо, но НЕ НАДО ИСПОЛЬЗОВАТЬ ФОРМАТ
xBtn Л_Проц, Л_Перехода, Кнопка.
ЭТО УБЛЮДОЧНЫЙ ЭРЗАЦ. Да, он будет несколько функциональнее обычного Btn - тем, что при нажатии можно будет вызвать дополнительную локацию через proc, но он НИКОГДА не приблизится по функционалу к существующему сейчас стандарту xBtn. Говоря человеческим языком - он не позволит реализовать некоторое количество алгоритмов, реализованных с помощью существующего xBtn (с фигурными скобками). Это я доказал абстрактно выше, когда отметил, что данный формат не имеет ВАРИАНТНОГО операнда.

Мой же вариант ЭКВИВАЛЕНТЕН существующему формату xBtn. То есть позволяет (возможно более длинным путем) полностью реализовать любой код, написанный с использованием существующего формата xBtn. Попробую и это доказать абстрактно.
С точки зрения программы нажатие пользователем на кнопку является ОДНИМ и только одним СОБЫТИЕМ. Как следствие, конечно же, может генерироваться еще множество событий, но все они будут иметь источником одно-единственное событие - нажатие на кнопку. Следовательно, описать это событие можно одним-единственным изменением данных, которыми оперирует программа - и это изменение и происходит при присвоении какого-то значения одной и только одной переменной.

предложение по БОЖИЕМУ СУДУ еще в силе.
Могу дополнить условия вызова:
вызываюсь привести любой код, написанный с использованием xBtn {произвольное количество произвольных операторов} к коду с использованием только xBtn {переменная=значение (один оператор)}, а оппонент пусть сделает то же самое то же самое, приведя код к использованию только xBtn {proc Локация}

Как было написано выше, данные конструкции имитируют соответственно мой вариант формата xBtn, и формат xBtn Локация1, Локация2, Кнопка

Имеющий мозги - ДА ВЪЕДЕТ, а не учит меня тому, что я и так знаю

------------------------------------------------------------------

Fireton!
Обалденная вещь! Вы как раз и предлагаете ИМЕННО ТО, что я имел в виду высказывая (возможно, невнятно) следующее (в первом своем посте здесь):

 цитата:
либо что то вроде

xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально
end

:Локация [Параметр]
Параметр = Параметр+Параметр.... и т.д.
end

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



то есть, вызов локации, КАК ПРОЦЕДУРЫ С ПАРАМЕТРАМИ
;)

И, раз уж вы говорите, что реализовать такой формат: xBtn (Пар1, ..., ПарN), Лока, Кнопа несложно, то я с радостью откажусь от ограничения на использование в xBtn ТОЛЬКО одной переменной (хотя и продолжу утверждать, что одной переменной достаточно - в математическом смысле этого слова)

Тогда, как я понимаю, нужно будет предусмотреть в URQL следующее:

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

:Лока Арг1, ... АргN

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

То есть, при вызове xBtn (Пар1, ..., ПарN), Лока, Кнопа присваивается значение системной переменной
КоличествоАргументов = N, а также набору типовых переменных Аргумент1 = Пар1...АргументN = ПарN, к каковым переменным мы и будем (при необходимости) обращаться в локации обработчике.


Спасибо: 0 
Профиль Цитата Ответить
Ответов - 73 , стр: 1 2 3 4 All [только новые]
Ответ:
1 2 3 4 5 6 7 8 9
видео с youtube.com картинка из интернета картинка с компьютера ссылка файл с компьютера русская клавиатура транслитератор  цитата  кавычки оффтопик свернутый текст

показывать это сообщение только модераторам
не делать ссылки активными
Имя, пароль:      зарегистрироваться    
Тему читают:
- участник сейчас на форуме
- участник вне форума
Все даты в формате GMT  3 час. Хитов сегодня: 15
Права: смайлы да, картинки да, шрифты нет, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет