нужно создать набор допустимых неймспейсов и смотреть на принадлежность класса именно этому пространству имен
Ну-ка, ну-ка, поподробнее. Как вы предлагаете это реализовать?
Например так:
делаем синтаксических анализатор и вытаскиваем конструкции вида
new Type, Type.Method, Type.Property, as Type, (Type), out Typе,
еще бы можно было-бы вытащить описание переменных, но и так будет работать.
В итоге имеем набор всех типов использованных в скрипте.
Дальше думаю, что объяснять не надо.
CAS вероятно будет удобнее, но всегда должна существовать альтернатива.
Здравствуйте, mslava, Вы писали:
M>Тогда почему Кармак для Quake написал QuakeC ?.. M> M>В Quake2 и Quake3 уже не было никакого QuakeC. M>Все писалось на С++ в виде dll.
Кармаг на С++? Скачай исходники того же Ку2 и попробуй там найти этот самый С++ Там все на С.
M>И вот как раз таки Кармак занимался изобретением колеса в виде QuakeC. M>Здесь все-таки другой подход. Язык уже есть.
Я тоже не понимаю зачем лабать свой скрпт. Но большинство игроделов используют тот или иной скрипт. И замена их на компилируемые языки точно даст выигрыш.
M>Думаю, что самый простой способ — запретить директиву using и самому подгружать допустимые неймспейсы.
А зачем? Есть же CAS и подпись сборок. Сборки от безопасных производителей поисываются как полностью доверительные. Остальные живут в CAS-песочнице.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ВВ>5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
С каких это пор JScript.NET стал интерпретатором?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>1. жава-скрипт сложнее с-шарпа? дело не в тонкостях языков — оцени опять-таки тот же "entry level" cost и там, и там.
Сдается мне, что JavaScript.NET отличается от Шарпа только тем, что поддериживает позднее связывание закомуфлированное под скриптовость. В остальном он или аналогичен Шарпу или уступает ему.
ВВ>2. А как код надо генерить? Автор хочет заставить с-шарп работать как процедурный язык — отсюда и необходимость "до-генерить" определение класса. жава-скрипт же и так поддерживает процедурное программивание.
Это где он такое сказал?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Использование C# как скрипта
От:
Аноним
Дата:
27.01.05 23:37
Оценка:
Кармаг на С++? Скачай исходники того же Ку2 и попробуй там найти этот самый С++ Там все на С.
Здравствуйте, VladD2, Вы писали:
ВВ>>5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
VD>С каких это пор JScript.NET стал интерпретатором?
Интерпретатор помимо всего прочего предполагает и определенное поведение — т.е. как бы "по-фазовое" исполнение скрипта. жава-скрипт.нет это прекрасно имитирует. Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа
Здравствуйте, VladD2, Вы писали:
VD>Сдается мне, что JavaScript.NET отличается от Шарпа только тем, что поддериживает позднее связывание закомуфлированное под скриптовость. В остальном он или аналогичен Шарпу или уступает ему.
Отличается еще и тем что имеет обратную совместимость с обычным жаваскрипт-ом, благодаря чему становится менее тяжеловесным.
ВВ>>2. А как код надо генерить? Автор хочет заставить с-шарп работать как процедурный язык — отсюда и необходимость "до-генерить" определение класса. жава-скрипт же и так поддерживает процедурное программивание. VD>Это где он такое сказал?
После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса
Здравствуйте, mslava, Вы писали:
M>Кармаг на С++? Скачай исходники того же Ку2 и попробуй там найти этот самый С++ Там все на С.
M>Это имеет какое-то значение что-ли?
Ну, тогда в следующий раз пиши "C#".
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Интерпретатор помимо всего прочего предполагает и определенное поведение — т.е. как бы "по-фазовое" исполнение скрипта. жава-скрипт.нет это прекрасно имитирует.
Ну, и пиши "похожее на скрипты поведение". А то вводишь людей в заблуждение.
ВВ>Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа
ВВ>alert("OK!"); fwefw
А зачем такие извращения? Статический контроль — это приемущество, а не недостаток.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Использование C# как скрипта
От:
Аноним
Дата:
28.01.05 12:14
Оценка:
Я имел в виду по отношении к данной задаче разве Ваше замечание имеет хоть какое-нибудь значение?
Мне очень жаль, если вы не поняли суть моего ответа по поводу QuakeC и так глупо приципились к языку, который использовался для написания Q2 и Q3.
ВВ>>Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа
ВВ>>alert("OK!"); fwefw
VD>А зачем такие извращения? Статический контроль — это приемущество, а не недостаток.
Не всегда. Особенно с при работе с неопределенными типами. А писать нужно много и быстро, а скорость выполнения не критична.
Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание.
При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mslava, Вы писали:
M>Я имел в виду по отношении к данной задаче разве Ваше замечание имеет хоть какое-нибудь значение? M>Мне очень жаль, если вы не поняли суть моего ответа по поводу QuakeC и так глупо приципились к языку, который использовался для написания Q2 и Q3.
По скриптам тут и говорить не очем. Ку — это графика. Разум в игре == 0. А все игры с мало-мальски интерактивной фауной напчканы скриптами по самые не боалуй.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание. S> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.
Что-то на практике от перехода с АСП на АСП.НЭТ скорость только увеличивается.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание. S> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.
Ну не настолько уж резко. Во первых у нетипизированного текста хуже читабельность, и вероятность опечаток обнаруживаемых только в рантайм. Во вторых в студии такой редактор что набор лишнего текста не вызывает сложностей.
По мне так вобще в большинстве случаев лучше писать такие вещи статически в студии, и в виде плагинов приделывать. Еще и отладчик получаем полноценный.
Здравствуйте, VladD2, Вы писали:
ВВ>>Интерпретатор помимо всего прочего предполагает и определенное поведение — т.е. как бы "по-фазовое" исполнение скрипта. жава-скрипт.нет это прекрасно имитирует. VD>Ну, и пиши "похожее на скрипты поведение". А то вводишь людей в заблуждение.
Хорошо, если я скажу, что неудачно выразился, то религиозная война закончится?
ВВ>>Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа ВВ>>alert("OK!"); fwefw VD>А зачем такие извращения? Статический контроль — это приемущество, а не недостаток.
ИМХО для скрипта это достоинство. Потом основная моя мысль была такой — если нужен "встраиваемый" язык сценариев, то лучше (проще) использовать жава-скрипт, чем си-шарп. Я тут чем-то не прав?
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Serginio1, Вы писали:
S>> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание. S>> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.
S_> Ну не настолько уж резко. Во первых у нетипизированного текста хуже читабельность, и вероятность опечаток обнаруживаемых только в рантайм. Во вторых в студии такой редактор что набор лишнего текста не вызывает сложностей.
S_> По мне так вобще в большинстве случаев лучше писать такие вещи статически в студии, и в виде плагинов приделывать. Еще и отладчик получаем полноценный.
Как старый 1С ник позволю несколько не согласится.
Но я выступаю за сочетание раннего и позднего связывания. Поверь мне во многих случаях когда поле является неопределенного типа читабельность с проверками типа резко уменьшится и количество кода тоже например когда ты знаешь, что у нескольких типов есть поле (метод, свойство) с одинаковым названием, но не происходящих от одного предка. Итд.
Мало того, такой подход даже расширяет ООП.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание. S>> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.
VD>Что-то на практике от перехода с АСП на АСП.НЭТ скорость только увеличивается.
С АСП не имел дело, но например при работе на Delphi с разными офисами во многих случаях плюешь на типизацию и работаешь с вариантами используя именованные параметры и тд. Все равно сильно скорости не поможет, а удобство очевидно.
Даешь больше языков с ранним и поздним связыванием
Например типизированный Pyton.
и солнце б утром не вставало, когда бы не было меня