Использование C# как скрипта - .NET

Обращаться к классам из других пространств имён можно и без директивы using (сюрприз!!!): new System.IO.FileStream( ... )
Я вам даже больше скажу: при желании "запретными" классами можно воспользоватся, даже если нет ссылки на нужную сборку. Вроде такого:

    Assembly a = Assembly.Load( "System.Drawing" );
    Type t = a.GetType( "System.Drawing.Image" );
    object image = Activator.CreateInstance( t );

Здесь спасёт только CAS, как уже было замечено выше.

Данная информация предоставляется на условиях «КАК ЕСТЬ», без предоставления каких-либо гарантий и прав. Используя данную информацию, вы соглашаетесь с тем, что (i) Майкрософт не несет ответственности за использование вами данной информации и (ii) вы принимаете на себя весь риск, связанный с использованием данной информации.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

нужно создать набор допустимых неймспейсов и смотреть на принадлежность класса именно этому пространству имен

Ну-ка, ну-ка, поподробнее. Как вы предлагаете это реализовать?

Например так:
делаем синтаксических анализатор и вытаскиваем конструкции вида
new Type, Type.Method, Type.Property, as Type, (Type), out Typе,
еще бы можно было-бы вытащить описание переменных, но и так будет работать.
В итоге имеем набор всех типов использованных в скрипте.
Дальше думаю, что объяснять не надо.

CAS вероятно будет удобнее, но всегда должна существовать альтернатива.

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Mityay, Вы писали:

M>1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".

Курите Code Access Security

M>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?

Скомпилировать с отладочной информацией. Для отладки этого достаточно, никаких проектов не нужно. Отлаживать можно не только при помощи студии — в состав .NET SDK входит бесплатный отладчик, по возможностям практически аналогичный студийному.

... << RSDN@Home 1.1.4 beta 3 rev. 302>>

Здравствуйте, Mityay, Вы писали:

Unmanaged debugger for F1.x
Managed debugger for F2.0

Здравствуйте, Аноним, Вы писали:

А>Вам это надо?
А>Есть JavaScript, где изучать (по сути) ничего не надо. Лично мне хватает справочника по элементам и dinamicdrive.com.

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

А>C# поддерживают только IE 5.0 и выше, ТЕ меньше 85% юзеров.

Хотелось бы знать, что Вы хотели этим сказать.
Во-первых, причем тут вообще IE. Связи между C# и IE не вижу в принципе.
Во-вторых, с чего Вы взяли, что IE 5.0 ? Это Visual Studio когда делаешь ASP.NET делает страницы зависимыми от броузера, а не C#

К тому же там такая опция есть: делать совместимыми с Netscape 3/ IE 3

А>Методы защиты...
А>Всегда можно библиотеку импортировать, где это будет, или из сети закачать тихой сапой, или bat-файл написать:
А>format C:\
А>shutdown /t 00 /f /r

В скрипте?

Который работает, по сути, в виртуальной машине? Это можно сделать только через дырки, но делать такие дырки явными — большая глупость.

А>Совсем запрещать писать в файлы — тоже не дело.

Не хочу Вас обидеть, но Вы не поняли моей цели. Предстапвьте себе компьютерную игру, например, Fallout. Или там DOOM III. Для описания игровой логики используются скрипты. Теперь подумайте: зачем скриптам писать что-то на диск? А если мы портируем игру на, например, PlayStation 2, то нам все скрипты переписывать?
В данном случае скрипты нужны для описания алгоритмов, а не их конкретной реализации и взаимодействия с аппаратными средствами.

А>Профессионалы себя ограничивать не станут.
А>По-моему, это — изобретение колеса.

Тогда почему Кармак для Quake написал QuakeC ?..

Тогда почему Кармак для Quake написал QuakeC ?..

В Quake2 и Quake3 уже не было никакого QuakeC.
Все писалось на С++ в виде dll.

И вот как раз таки Кармак занимался изобретением колеса в виде QuakeC.
Здесь все-таки другой подход. Язык уже есть.

Думаю, что самый простой способ — запретить директиву using и самому подгружать допустимые неймспейсы.

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Воронков Василий, Вы писали:

AVK>>С чего ты взял что JScript.NET это интерпретатор?

ВВ>Да какая разница что он там делает. Главное то, что он ведет себя как интерпретатор с т.з. клиентского кода. Т.е. считай что у компилятора есть режим подражания интерпретатору. Для С-шарпа это придется делать ручками.

Вот это не соответствует действительности

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

... << RSDN@Home 1.1.4 beta 3 rev. 302>>

Здравствуйте, Воронков Василий, Вы писали:

AVK>>Вот это не соответствует действительности
AVK>>

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

ВВ>Что не соответствует действительности?

То что JScript.NET значительно легче C#, то что не надо генерить дополнительный код, то что отладочная информация в JScript.NET чем то отличается от онной в C#.

ВВ> Или ты исходишь из того, что скриптовый язык == интерпретируемый? Для меня скорее это область применения.

Это не я исхожу, это ты исходишь.

... << RSDN@Home 1.1.4 beta 3 rev. 302>>

Здравствуйте, Silver_s, Вы писали:

S_>Здравствуйте, Serginio1, Вы писали:

S>> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание.
S>> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.

S_> Ну не настолько уж резко. Во первых у нетипизированного текста хуже читабельность, и вероятность опечаток обнаруживаемых только в рантайм. Во вторых в студии такой редактор что набор лишнего текста не вызывает сложностей.

S_> По мне так вобще в большинстве случаев лучше писать такие вещи статически в студии, и в виде плагинов приделывать. Еще и отладчик получаем полноценный.
Как старый 1С ник позволю несколько не согласится.
Но я выступаю за сочетание раннего и позднего связывания. Поверь мне во многих случаях когда поле является неопределенного типа читабельность с проверками типа резко уменьшится и количество кода тоже например когда ты знаешь, что у нескольких типов есть поле (метод, свойство) с одинаковым названием, но не происходящих от одного предка. Итд.
Мало того, такой подход даже расширяет ООП.

Мною задумно использование языка C# (впрочем, это не суть важно — подойдет любой язык из .NET) в качестве скриптового в приложении. Данный выход мне кажется удобным тем, что:

1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET
2. Язык известен — его не надо изучать!
3. Прямая привязка к объектам в "воображаемом" мире, в котором и дейтсвуют скрипты

После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса, т.е. скрипт начинает принадлежать определенному классу, у которого есть ссылка на другие объекты мира и т.п. Все работает "на ура" и очень быстро, но подумав еще немного, я увидел несколько проблем, связанных с этим подходом. Не подскажет ли уважаемый All, как это можно побороть?

Итак:

1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".

2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?

Курите Code Access Security

Имеется ввиду, что он курит такую знатную траву "Code Access Security" и ему именно поэтому захотелось использовать C# для скрипта ?

P.S. Серьезно
А что значит купить? разве оно в составе FW не идет? эээ...

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>C# поддерживают только IE 5.0 и выше, ТЕ меньше 85% юзеров.

Причем здесь IE? Ему надо скрипт писать для своего собственного приложения.

Я в одном своем приложении тоже реализовал возможность написания скриптов на C# с помощью встроенного редактора (я туда еще Intellisense примитвный прикрутил, чтоб удобнее писать было).

Пространства имен я никак не ограничивал — зачем? Пускай человек делает все, что хочет.

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

eisernWolf

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, AndrewVK, Вы писали:

M>>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?

AVK>Скомпилировать с отладочной информацией. Для отладки этого достаточно, никаких проектов не нужно. Отлаживать можно не только при помощи студии — в состав .NET SDK входит бесплатный отладчик, по возможностям практически аналогичный студийному.

Можете навести на ссылки, где об этом написано более подробно? Или приведите пример использования такого средства, пожалуйста.

Здравствуйте, Mityay, Вы писали:

M>Мною задумно использование языка C# (впрочем, это не суть важно — подойдет любой язык из .NET) в качестве скриптового в приложении. Данный выход мне кажется удобным тем, что:

M>1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET
M>2. Язык известен — его не надо изучать!
M>3. Прямая привязка к объектам в "воображаемом" мире, в котором и дейтсвуют скрипты

M>После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса, т.е. скрипт начинает принадлежать определенному классу, у которого есть ссылка на другие объекты мира и т.п. Все работает "на ура" и очень быстро, но подумав еще немного, я увидел несколько проблем, связанных с этим подходом. Не подскажет ли уважаемый All, как это можно побороть?

M>Итак:

M>1. Каким образом мне ограничить скрипт-код так, чтобы он мог обращаться только к заранее заданному списку Namespace'ов и/или классов? Или скажу проще: как мне не дать скрипту использовать, например, System.IO для ликвидации потенциальной возможности работы с данными на жестком диске пользователя из скрипта? Думается мне, проверка кода скрипта на вхождение определенных символов и слов глупа — защитит только от "новичков".

M>2. Как мне отлаживать подобные приложения? Сколняюсь к мысли, что надо написать утилиту, которая будет каким-то образом сначала генерировать весь код в проект Microsoft Visual Studio, затем присоединять его к Solution с кодом самого большого проекта и все это запускать на отладку. Но такой метод очень громоздок и, признаться, я просто не уверен, что потяну его. Другие варианты?

На самом деле я бы советовал использовать JavaScript.NET. Плюсы:

1. Не нужно писать компилятор/транслятор/интерпретатор — есть встроенные средства в .NET (на сайте есть пример Михайлика, кажется в Файлах, касательно того как все это дело можно приручить).
2. Язык известен — его не надо изучать! На самом деле куда более известен чем до-диез. (Если даже вдруг не знаешь javascript, то — на JS.NET можно писать в стиле обычного старого JS, "entry level" для к-го при наличии знании С-подобного языка, дается за 5 минут. Серьезно).
3. При желании есть ООП и типы. Хочешь юзай — хочешь нет.
4. Легко ограничить или вообще запретить доступ к стандартному АПИ дотнета.
5. Легко написать как бы собственный "рантайм" или создать своего рода хост для скрипта — просто создаешь классы с нужными функциями и объектами, которые затем регистрируешь у интерпретатора (пример также есть у Михайлика) — и можно будет обеспечить доступ к нужному функционалу только посредством таких ф-ций. Это немного тяжелое решение, так как придется писать классы-врапперы над стандартным АПИ, зато наиболее естественное для скрипта.
5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.
6. Касательно отладки. Есть вроде и стандартные средства типа команды debugger, аналогичной установке брейк-поинта. Но правда не юзал. Отладочный вывод легко организовать через те же функции расширения. В общем тут конечно не все безоблачно, но workaround бесспорно есть. Самое простое — т.к. жава-скрипт.нет и интерпретируемый и компилируемый, то можно для отладки компилить его и дебажить гуи-дебагером из СДК. Вкупе с debugger должно выйти вполне полноценное решение.

Здравствуйте, Mityay, Вы писали:

M>Можете навести на ссылки, где об этом написано более подробно? Или приведите пример использования такого средства, пожалуйста.

Открываешь каталок .NET SDK, заходишь в директорию GuiDebug и запускаешь DbgCLR.exe. Дальше все пронятно.

... << RSDN@Home 1.1.4 beta 3 rev. 302>>

Здравствуйте, Воронков Василий, Вы писали:

С чего ты взял что JScript.NET это интерпретатор?

... << RSDN@Home 1.1.4 beta 3 rev. 302>>

Согласен, c using'ом немного тормознул.
На самом деле я имел ввиду то, что нужно создать набор допустимых неймспейсов и смотреть на принадлежность класса именно этому пространству имен.

т.е. запретить(не включать в список допустимых) в принципе System.Reflection и динамическая загрузки сборки сразу же не пройдет.

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, AndrewVK, Вы писали:

AVK>С чего ты взял что JScript.NET это интерпретатор?

Да какая разница что он там делает. Главное то, что он ведет себя как интерпретатор с т.з. клиентского кода. Т.е. считай что у компилятора есть режим подражания интерпретатору. Для С-шарпа это придется делать ручками.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, AndrewVK, Вы писали:

AVK>Вот это не соответствует действительности
AVK>

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

Что не соответствует действительности? Или ты исходишь из того, что скриптовый язык == интерпретируемый? Для меня скорее это область применения.

Здравствуйте, AndrewVK, Вы писали:

AVK>То что JScript.NET значительно легче C#, то что не надо генерить дополнительный код, то что отладочная информация в JScript.NET чем то отличается от онной в C#.

1. жава-скрипт сложнее с-шарпа? дело не в тонкостях языков — оцени опять-таки тот же "entry level" cost и там, и там.
2. А как код надо генерить? Автор хочет заставить с-шарп работать как процедурный язык — отсюда и необходимость "до-генерить" определение класса. жава-скрипт же и так поддерживает процедурное программивание.

А конкретно чем Вас не устраивает CAS?

Например:

UIPermission MyPermission = new UIPermission(PermissionState.Unrestricted);
MyPermission.PermitOnly();

Так Вы обережете свой скрипт и от таких действий:

System.Type killT= Type.GetType("System.IO.File");
MethodInfo mi = killT.GetMethod("Delete", new Type[] {Type.GetType("System.String")} );
mi.Invoke(killT,new object[] {"file1.txt"});

И от многих других.

> CAS вероятно будет удобнее, но всегда должна существовать альтернатива.

CAS будет невероятно удобнее.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

А конкретно чем Вас не устраивает CAS?

Если Вы обратите внимание, то я нигде не высказывался против CAS. Соответственно и против ничего не имею, равно как и за.

Я с CAS не работал.

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, mslava, Вы писали:

M>P.S. Серьезно
M>А что значит купить? разве оно в составе FW не идет? эээ...

Значит что надо почитать литературу в этом направлении.

... << RSDN@Home 1.1.4 beta 4 rev. 306>>

Здравствуйте, 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>>

Кармаг на С++? Скачай исходники того же Ку2 и попробуй там найти этот самый С++ Там все на С.

Это имеет какое-то значение что-ли?

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, VladD2, Вы писали:

ВВ>>5. Жава-скрипт это все скриптовый язык, он значительно легче до-диезе. Не надо будет генерить дополнительный код. к тому же при возникновении ошибки в скрипте всегда сможешь поймать исключение в к-м будет точно идентифицирован токен, на к-м свалился интерпретатор.

VD>С каких это пор JScript.NET стал интерпретатором?

Интерпретатор помимо всего прочего предполагает и определенное поведение — т.е. как бы "по-фазовое" исполнение скрипта. жава-скрипт.нет это прекрасно имитирует. Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа

alert("OK!"); fwefw

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, VladD2, Вы писали:

VD>Сдается мне, что JavaScript.NET отличается от Шарпа только тем, что поддериживает позднее связывание закомуфлированное под скриптовость. В остальном он или аналогичен Шарпу или уступает ему.

Отличается еще и тем что имеет обратную совместимость с обычным жаваскрипт-ом, благодаря чему становится менее тяжеловесным.

ВВ>>2. А как код надо генерить? Автор хочет заставить с-шарп работать как процедурный язык — отсюда и необходимость "до-генерить" определение класса. жава-скрипт же и так поддерживает процедурное программивание.
VD>Это где он такое сказал?

После некоторый раздумий я написал код, который обрамляет написанную на C# скрипт-функцию телом класса

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, 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>>

Я имел в виду по отношении к данной задаче разве Ваше замечание имеет хоть какое-нибудь значение?
Мне очень жаль, если вы не поняли суть моего ответа по поводу QuakeC и так глупо приципились к языку, который использовался для написания Q2 и Q3.

С Уважением, Вячеслав.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, VladD2, Вы писали:

ВВ>>Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа

ВВ>>alert("OK!"); fwefw

VD>А зачем такие извращения? Статический контроль — это приемущество, а не недостаток.
Не всегда. Особенно с при работе с неопределенными типами. А писать нужно много и быстро, а скорость выполнения не критична.

Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание.
При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.

Здравствуйте, mslava, Вы писали:

M>Я имел в виду по отношении к данной задаче разве Ваше замечание имеет хоть какое-нибудь значение?
M>Мне очень жаль, если вы не поняли суть моего ответа по поводу QuakeC и так глупо приципились к языку, который использовался для написания Q2 и Q3.

По скриптам тут и говорить не очем. Ку — это графика. Разум в игре == 0. А все игры с мало-мальски интерактивной фауной напчканы скриптами по самые не боалуй.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Что-то на практике от перехода с АСП на АСП.НЭТ скорость только увеличивается.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, Serginio1, Вы писали:

S> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание.
S> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.

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

По мне так вобще в большинстве случаев лучше писать такие вещи статически в студии, и в виде плагинов приделывать. Еще и отладчик получаем полноценный.

Здравствуйте, VladD2, Вы писали:

ВВ>>Интерпретатор помимо всего прочего предполагает и определенное поведение — т.е. как бы "по-фазовое" исполнение скрипта. жава-скрипт.нет это прекрасно имитирует.
VD>Ну, и пиши "похожее на скрипты поведение". А то вводишь людей в заблуждение.

Хорошо, если я скажу, что неудачно выразился, то религиозная война закончится?

ВВ>>Попробуй в интерпретаторе Михайлика запустить на исполнение строку типа
ВВ>>alert("OK!"); fwefw
VD>А зачем такие извращения? Статический контроль — это приемущество, а не недостаток.

ИМХО для скрипта это достоинство. Потом основная моя мысль была такой — если нужен "встраиваемый" язык сценариев, то лучше (проще) использовать жава-скрипт, чем си-шарп. Я тут чем-то не прав?

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

S>> Вот здесь как раз вырождается в недостаток. Вообще идеальный язык это поддерживающий не только раннее но и позднее связывание.
S>> При этом количество кода можно резко сократить, и производительность кодирования резко увеличить.

VD>Что-то на практике от перехода с АСП на АСП.НЭТ скорость только увеличивается.
С АСП не имел дело, но например при работе на Delphi с разными офисами во многих случаях плюешь на типизацию и работаешь с вариантами используя именованные параметры и тд. Все равно сильно скорости не поможет, а удобство очевидно.
Даешь больше языков с ранним и поздним связыванием
Например типизированный Pyton.

Здравствуйте, Serginio1, Вы писали:

S> С АСП не имел дело, но например при работе на Delphi с разными офисами во многих случаях плюешь на типизацию и работаешь с вариантами используя именованные параметры и тд. Все равно сильно скорости не поможет, а удобство очевидно.

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

S> Даешь больше языков с ранним и поздним связыванием
S> Например типизированный Pyton.

Нчено. И тебя вычичим (с).

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>ИМХО для скрипта это достоинство.

То есть достоинство когда програма (будь она хоть трижды скрипт) сваливается в середине, а не выдает сообщение об ошибке при старте? Странная логика.

От скриптов нужно только одно — интерактивность. И то не всегда. Если как раз вести речь о играх, то интерактивности C#-а выше крыши. А полноценные возможности ООП и т.п. будут только к стати.

ВВ> Потом основная моя мысль была такой — если нужен "встраиваемый" язык сценариев, то лучше (проще) использовать жава-скрипт, чем си-шарп.

Вот и не ясно чем? Я вижу только более быстрый запуск и отсуствие необходимости оборачивать функции в классы. И ничего более. Меньшая надежность я лично к достоинствам не отношу. Вот и хотелось бы услышать о других достоинствах. А то ты советущь, но рельные плюсы не описываешь. Зато приводишь очень сомнительные оаргументы.

ВВ> Я тут чем-то не прав?

Да. Аргументация ни к черту.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
> Есть же CAS и подпись сборок.

Сборки от безопасных производителей поисываются как полностью доверительные. Остальные живут в CAS-песочнице.

Между тем, в террариуме сборки контролировались не только с использованием CAS

Posted via RSDN NNTP Server 1.9

Здравствуйте, VladD2, Вы писали:

VD>Да. Аргументация ни к черту.

Уж если отвечашь, то давай более менее реальную картину. Тогда каждый сможет сделать вывод кторый ему нужен. Один сочет гигбостью скриптоподобную компиляцию. Другой большие возможности языка, и более стройный синтаксис.

Мне кажется что более быстрый запуск, поддержка процедурного программирования и возможность создавать собственные стандартные функции — т.е. расширять функциональность в процедурном ключе — это уже довольно мощные плюсы. К тому же жаваскрипт знает больше людей, чем си-шарп; он проще для освоения и использования именно благодаря позднему связыванию и нетипизированности. Думаю, что человеку который вообще не является программистом освоить будет проще именно жава-скрипт. Вот почему например для офиса выбрали именно VBA, не задумывался?

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

В Delphi есть классы оболочки для более простого использования. Если бы ты просматривал эти tlb-хи то увидел бы массу методов с огромным количеством методов с огромным количеством параметров по умолчанию. И вместо писания кучи emptyparam легче использовать именованные параметры. Кстати не плохо было бы и в нет ввести такой подход, где в качестве параметров выступала Хэштаблица а параметры передавались как

объявив как void Method( param Hahtable L)
и вызов
Method(str:=1,str2;="2")

Другое. Например твоя любимая 1С. Создание движка на аналоге Idispatch намного проще чем через компилируемые классы, да и уровень программистов для работы с ней нужен не такой и крутой.
Работа же с типизированными данными не намного сложнее, но вот архитектура классов не такая уж и тривиальная. И уровень программистов должен быть намного выше. Плюс сложности работы с полями неопределенного типа.
Я сам сторонник типизации (удавлюсь за ненужный тик), но во многих случаях нужно искать золотую середину. Поэтому языки поддерживающие как позднее так и ранне связывание дают бОльшую гибкость, и отвергать позднее связывание все же не стоит.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

S>> С АСП не имел дело, но например при работе на Delphi с разными офисами во многих случаях плюешь на типизацию и работаешь с вариантами используя именованные параметры и тд. Все равно сильно скорости не поможет, а удобство очевидно.

VD>Извини это откровенная халтура. Вместо того чтобы плюваться нужно было просто подключить tlb-хи. Ну, а для дотнета это в двойне верно.

S>> Даешь больше языков с ранним и поздним связыванием
S>> Например типизированный Pyton.

VD>Нчено. И тебя вычичим (с).

Переведи!!!

Приведу несколько примеров где позднее связывание проще и лучше.

Допустим объект реализует интерфейс

 interface IDispatcher
 { 
   object PropertyOrMethod[string PropertyName] {get,set};
   object PropertyArray[string PropertyName,params object[] parameters] {get,set};
   object Method (string PropertyName,params object[] parameters);
   }


  }

Для примера возьмем DataTable
выразительней запись row.Товар нежели row["Товар"].
Компилятор не встретив свойства с параметрами может полезть и посмотреть поддерживает ли данный тип IDispatcher и вызвать соответствующий метод. По скорости будет то же самое, а по читабельности совсем по другому. В кай то момент кто то захочет работать с типизированными DataTable и переделывать ничего не надо.
Следующий пример, опять же из позднего связывания при работе с XML.
Можно получать атрибуты более простым путем и выполнение методов.

Еще пример Remoting. Можно легко обойтись без TP и RP. Яркий пример TSocketConnection в Delphi с использованием IDispatch. Причем переход от TSocketConnection к ТComConnection достаточно прост.

Динамические классы.

Во многих случаях позднее связывание это отнюдь не рефлексия (хотя и она может использоваться)

Чем больше язык поддерживает фич, тем гибче, быстрее программирование.

А во всем остальном я полностью с тобой согласен.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, Serginio1, Вы писали:

S>>> С АСП не имел дело, но например при работе на Delphi с разными офисами во многих случаях плюешь на типизацию и работаешь с вариантами используя именованные параметры и тд. Все равно сильно скорости не поможет, а удобство очевидно.

VD>>Извини это откровенная халтура. Вместо того чтобы плюваться нужно было просто подключить tlb-хи. Ну, а для дотнета это в двойне верно.

S>>> Даешь больше языков с ранним и поздним связыванием
S>>> Например типизированный Pyton.

VD>>Нчено. И тебя вычичим (с).

S> Переведи!!!

S> Приведу несколько примеров где позднее связывание проще и лучше.

S> Допустим объект реализует интерфейс
S>

S> interface IDispatcher
S> { 
S>   object PropertyOrMethod[string PropertyName] {get,set};
S>   object PropertyArray[string PropertyName,params object[] parameters] {get,set};
S>   object Method (string PropertyName,params object[] parameters);
S>   }


S>  }
S>

S>Для примера возьмем DataTable
S> выразительней запись row.Товар нежели row["Товар"].
S> Компилятор не встретив свойства с параметрами может полезть и посмотреть поддерживает ли данный тип IDispatcher и вызвать соответствующий метод. По скорости будет то же самое, а по читабельности совсем по другому. В кай то момент кто то захочет работать с типизированными DataTable и переделывать ничего не надо.
S> Следующий пример, опять же из позднего связывания при работе с XML.
S> Можно получать атрибуты более простым путем и выполнение методов.

S> Еще пример Remoting. Можно легко обойтись без TP и RP. Яркий пример TSocketConnection в Delphi с использованием IDispatch. Причем переход от TSocketConnection к ТComConnection достаточно прост.

S> Динамические классы.

S> Во многих случаях позднее связывание это отнюдь не рефлексия (хотя и она может использоваться)

S> Чем больше язык поддерживает фич, тем гибче, быстрее программирование.

S> А во всем остальном я полностью с тобой согласен.

Че та я не понял

http://www.qwhale.net/

Scripter.NET

Здравствуйте.

Я так понял что тут все в курсе как же в рантайме превратить текст на с# в компилированный код и исполнить его.
Будте добры подскажите...

Спасибо всем.

А>Че та я не понял
А>http://www.qwhale.net/
А>Scripter.NET

А нафига эта хрень нужна, если

Scripter.NET uses VSA technology

?
С VSA разобраться лень? У которого, в общем-то минусов хватает и значит, этот Scripter.NET тоже их за собой тянет

Здравствуйте, TK, Вы писали:

TK>Между тем, в террариуме сборки контролировались не только с использованием CAS

Ты бы рассказал, если знашь что-то конкретное. Было бы дело.

ЗЫ

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

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, Serginio1, Вы писали:

S>В Delphi есть классы оболочки для более простого использования. Если бы ты просматривал эти tlb-хи то увидел бы массу методов с огромным количеством методов с огромным количеством параметров по умолчанию. И вместо писания кучи emptyparam легче использовать именованные параметры. Кстати не плохо было бы и в нет ввести такой подход, где в качестве параметров выступала Хэштаблица а параметры передавались как

VB.Net тебе в руки. Дотнет тут не причем.

S>

данное сообщение получено с www.gotdotnet.ru
S>ссылка на оригинальное сообщение

Чё это ты с ГДН-а пишешь?

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, Serginio1, Вы писали:

VD>>Нчено. И тебя вычичим (с).

S> Переведи!!!

Пальцы слетели. Говорю... ничего и тебя вылечим.

S>Для примера возьмем DataTable
S> выразительней запись row.Товар нежели row["Товар"].

Думаю, что допускать особо нечего. В крайнем случае делаешь обертки и вперед. А пользоваться ненадежным поздним связыванием — это друной стиль.

S> Чем больше язык поддерживает фич, тем гибче, быстрее программирование.

Вот Перл поддерживает очень много фич. Но это привело только к тому, что язык снискал дурную славу сложного в чтении. Излишня гибкость, как и свобода, приводит к вседозволенности и бардаку. Так что разумные ограничения — это очень правильный подход. Лучше уж если что взять дургой язык. Тот же VB.Net прекрасно подходит под твои требования.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
> TK>Между тем, в террариуме сборки контролировались не только с
> использованием CAS
> Ты бы рассказал, если знашь что-то конкретное. Было бы дело.
>

Ситуации бывают разные. Например, может быть необходимо запретить
использование потоков, статических переменных, разрешить работу только с
узким набором заранее определенных классов и т.п.

Posted via RSDN NNTP Server 1.9 alpha

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, VladD2, Вы писали:

VD>>Да. Аргументация ни к черту.

Уж если отвечашь, то давай более менее реальную картину. Тогда каждый сможет сделать вывод кторый ему нужен. Один сочет гигбостью скриптоподобную компиляцию. Другой большие возможности языка, и более стройный синтаксис.

ВВ>Мне кажется что более быстрый запуск,

У VB.Net запуск не быстрее. И все же ее в студии испльзуют.

ВВ> поддержка процедурного программирования

Разве что. Но я бы на это забил.

ВВ> и возможность создавать собственные стандартные функции — т.е. расширять функциональность в процедурном ключе

Для этого можно и класс завести.

ВВ> — это уже довольно мощные плюсы.

Несказал бы.

Особенно если на скрипты предпологается возлажить серьезные задачи вроде сценариев в играх. Тут уж точно шарп будет лучше. Хотя еще лучше просто сменяемый язык. Например, распознавать язык скрипта по расширению файла.

ВВ> К тому же жаваскрипт знает больше людей, чем си-шарп;

На некотором уровне разницы ты не заметишь. А далее Шарп окажется предпочтительнее просто из-за большего удобства языка. В общем, опять же нужно смотреть на аудиторию которой прийдется пользоваться скриптом. Для игр я бы выбрал Шарп, а для расширения некого дескоп-приложения возможно и ЯваСкрип.

ВВ> он проще для освоения

Не думаю. Проще в нем только позднее связывание.

ВВ> и использования именно благодаря позднему связыванию и нетипизированности.

Опять же. Это далеко не приемушства. Вернее не всегда приемущества. Хороший программист предпочтет более мощьный язык и типобезопастность в компайлтайме. Так что оять таки из плюсов остается только расчет на знание пользователями ЯваСкрипа.

ВВ> Думаю, что человеку который вообще не является программистом освоить будет проще именно жава-скрипт. Вот почему например для офиса выбрали именно VBA, не задумывался?

Это ты о студии? Задумывался. И пришел к мнению, что это глупое решение. Или у них уже был котов некий вариант порта с ВБА. Я все время матерюсь когда приходится перекдючаться на ВБ при написании макросов. Шарп был бы для меня намного удобнее. Ну, и ЯваСкрипта там как-то тоже нет.

ЗЫ

В общем, если предпологается что эти скрипты будут писать программисты, то лучше сделать сменяемые скрипты или остановитьс на Шарпе. Если же это так для автоматизации некомпетентными орлами, то можно и ЯваСкриптом обойтись. Ну, а многоязычие оно всегда будет удобнее.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

VD>>>Нчено. И тебя вычичим (с).

S>> Переведи!!!

VD>Пальцы слетели. Говорю... ничего и тебя вылечим.

S>>Для примера возьмем DataTable
S>> выразительней запись row.Товар нежели row["Товар"].

VD>Думаю, что допускать особо нечего. В крайнем случае делаешь обертки и вперед. А пользоваться ненадежным поздним связыванием — это друной стиль.

Можно и без оберток, со соим DataTable. Разговор не об этом.
В свое время создал движок к 1С на IDispatch на Delphi где то недели за две. На типизированный аналог затратил месяца 4 с последующими доводкаим.
В 1С объекты по своей сути различаются только свойствами. И зная метаданные легко построить филды отвечающие за свое свойство. И одинажды написанные классы будут работать со всеми конфигурациями. С типизированными классами это сложнее, т.к. для уменьшения оверхедов используется раннее связывание, и при изменении структур данных приходится пересоздавать объекты с последующей компиляцией. Генерируемые исходники занимают мегабайты. Но зато выигрыш по скорости огромный.
Но использую их только в критических по времени вычислениях. Т.к. сегодняшних гигагерцев вполне зватает и для интерпитируемой + диспачной 1С.

S>> Чем больше язык поддерживает фич, тем гибче, быстрее программирование.

VD>Вот Перл поддерживает очень много фич. Но это привело только к тому, что язык снискал дурную славу сложного в чтении. Излишня гибкость, как и свобода, приводит к вседозволенности и бардаку. Так что разумные ограничения — это очень правильный подход. Лучше уж если что взять дургой язык. Тот же VB.Net прекрасно подходит под твои требования.
Не мне ява скрипт больше нравится, да и Delphi наверное перенесет из натива позднее связывание, которое кстати было очень удобно.

Здравствуйте, TK, Вы писали:

TK>Ситуации бывают разные. Например, может быть необходимо запретить
TK>использование потоков, статических переменных, разрешить работу только с
TK>узким набором заранее определенных классов и т.п.

Это как раз все можно с помощью CAS.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

TK>>Ситуации бывают разные. Например, может быть необходимо запретить
TK>>использование потоков, статических переменных, разрешить работу только с
TK>>узким набором заранее определенных классов и т.п.

VD>Это как раз все можно с помощью CAS.

Ну, запрети использование данного класса средствами CAS

class A
{
   static int a = 7;
}

Здравствуйте, TK, Вы писали:

TK>Ну, запрети использование данного класса средствами CAS
TK>

TK>class A
TK>{
TK>   static int a = 7;
TK>}
TK>

Статиками вообще наверно не удастся. Но зачем это делать? А с конкретными классами без проблем.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

Ладно, хрен с ним с жава-скритом.

Поздравляю с возвращением РСДН в жизни!

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Поздравляю с возвращением РСДН в жизни!

И вас так же.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
> Статиками вообще наверно не удастся. Но зачем это делать?

Чтобы, всякие уроды память не личили.

> А с конкретными классами без проблем.

Давай. Запрети создание новых потоков (класс System.Threading.Thread.
Только, запретить надо именно создание, а не выполнение кода вообще) или
получение текущей даты (DateTime.Now).

Posted via RSDN NNTP Server 1.9 alpha

Здравствуйте, TK, Вы писали:

>> Статиками вообще наверно не удастся. Но зачем это делать?

TK>Чтобы, всякие уроды память не личили.

Можно тут поподробнее?

>> А с конкретными классами без проблем.

TK>Давай. Запрети создание новых потоков (класс System.Threading.Thread. Только, запретить надо именно создание, а не выполнение кода вообще) или получение текущей даты (DateTime.Now).

В смысле запретить доступ к классам из mscorlib.dll?

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
>>> Статиками вообще наверно не удастся. Но зачем это делать?
>
> TK>Чтобы, всякие уроды память не личили.
> Можно тут поподробнее?

Куда уж подробнее?

>>> А с конкретными классами без проблем.

>
> TK>Давай. Запрети создание новых потоков (класс System.Threading.Thread.
> Только, запретить надо именно создание, а не выполнение кода вообще) или
> получение текущей даты (DateTime.Now).
> В смысле запретить доступ к классам из mscorlib.dll?

Нет. нужно запретить доступ к System.Threading.Thread. Это-же не я сказал,
что "А с конкретными классами без проблем".

Posted via RSDN NNTP Server 1.9 alpha

Здравствуйте, TK, Вы писали:

TK>Куда уж подробнее?

Да ты вообще ничего не сказал.

Одни намеки.

TK>Нет. нужно запретить доступ к System.Threading.Thread. Это-же не я сказал,
TK>что "А с конкретными классами без проблем".

Дык выводи описания классов куда нужно (делай обертки) и давай права. С системными сборками сложнее конечно.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

TK>>Куда уж подробнее?
VD>Да ты вообще ничего не сказал.

Одни намеки.

хм. рассказать как устроить leak памяти через статическое поле?

TK>>Нет. нужно запретить доступ к System.Threading.Thread. Это-же не я сказал,
TK>>что "А с конкретными классами без проблем".

VD>Дык выводи описания классов куда нужно (делай обертки) и давай права. С системными сборками сложнее конечно.

Ничего не понял из того, что ты сказал... в любом случае твоего решения для "А с конкретными классами без проблем" не вижу.

от CAS достаточно того, что это полноценно не работает с системными сборками. С не системными — это, вообще, дыра в безопасности сравнимая со скриптами в браузере.

Здравствуйте, TK, Вы писали:

TK>хм. рассказать как устроить leak памяти через статическое поле?

Ага. И за одно расскажи что помешает мне устроить аналогичный на базе поля живого объекта. Но хоть что-то. А то одни загадки.

TK>от CAS достаточно того, что это полноценно не работает с системными сборками. С не системными — это, вообще, дыра в безопасности сравнимая со скриптами в браузере.

Вот тут тоже можно бы по подробнее.

ЗЫ

А про скрипты в броузере — это ты зря. Сами по себе они дырой не являются. В той же опере и т.п. они живут без проблем. Да и в ИЕ вроде как научились работать более менее безопасно. От ссылок на экзешники куда больше проблем. А ведь они то к скриптам отношения не имеют.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
> TK>хм. рассказать как устроить leak памяти через статическое поле?
>
> Ага. И за одно расскажи что помешает мне устроить аналогичный на базе поля живого объекта. Но хоть что-то. А то одни загадки.
>

Живой объект (при контроле его внешних отношений) легко собирается сборщиком мусора.

> TK>от CAS достаточно того, что это полноценно не работает с системными сборками. С не системными — это, вообще, дыра в безопасности сравнимая со скриптами в браузере.
>
> Вот тут тоже можно бы по подробнее.
>
> ЗЫ
> А про скрипты в броузере — это ты зря. Сами по себе они дырой не являются.

Я и не утверждал, что именно скрипты являются дырой в безопасности. Дыра в безопасности — сторонние компоненты. И, как сам видишь — CAS от сторонних компонент (также как и не от сторонних) не всегда помогает.

Posted via RSDN NNTP Server 1.9

Здравствуйте, TK, Вы писали:

TK>Живой объект (при контроле его внешних отношений) легко собирается сборщиком мусора.

Это как? Или он живой. Или он собирается.

TK>Я и не утверждал, что именно скрипты являются дырой в безопасности. Дыра в безопасности — сторонние компоненты. И, как сам видишь — CAS от сторонних компонент (также как и не от сторонних) не всегда помогает.

Ну, вот и интересно было бы послушать развернутые соображения. Я лично в CAS очень глубоко не вникал. Если знашь какие-то подводные грабли, то поведал бы.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, TK, Вы писали:

TK>>Живой объект (при контроле его внешних отношений) легко собирается сборщиком мусора.

VD>Это как? Или он живой. Или он собирается.

Живой — значит не собрали (и без разницы, есть сильная ли ссылка или слабая). Не живой — значит ObjectDisposedException.

VD>Ну, вот и интересно было бы послушать развернутые соображения. Я лично в CAS очень глубоко не вникал. Если знашь какие-то подводные грабли, то поведал бы.

Пожалуй, соглашусь

Здравствуйте, Mika Soukhov, Вы писали:

MS>Живой — значит не собрали (и без разницы, есть сильная ли ссылка или слабая). Не живой — значит ObjectDisposedException.

Не, батенька. Или живой, или нет. Если объект не достижим, то он мертв.

А ObjectDisposedException тут вообще не причем. Это вообще чисто логическое исключение. Если уж говорить о финализируемых объектах, то их держит очередь фнализации, так что они живут не менее двух сборок. Но это все частности.

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

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Hello, "VladD2"
>
> MS>Живой — значит не собрали (и без разницы, есть сильная ли ссылка или
> слабая). Не живой — значит ObjectDisposedException.
> Не, батенька. Или живой, или нет. Если объект не достижим, то он мертв.
>

Не надо рассмотривать "живой/мертвый" в таком примитивном контексте. Объект
может быть живым/мертвым по отношению к какой-либо подсистеме. Если внешняя
подсистема в единственном числе владеет ссылками на объект, то при наличии
достаточного контроля можно считать, что именно эта подсистема управляет
временем жизни объекта.

PS
Никто не мешает "недостижимым" объектам и воскресать...

Posted via RSDN NNTP Server 1.9 alpha

Здравствуйте, TK, Вы писали:

TK>Никто не мешает "недостижимым" объектам и воскресать...
Вам надо завести топик "Объект скорее жив чем мертв" vs "Объект скорее мертв чем жив"

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Мне однажды потребовалась возможность написание макросов к моей программе, в принципе у меня все получилось, единственное редактор макросов нужно писать самому т.е. если редактор макросов на VB я по сути должен знать все встроенные функции и конструкции языка (чтобы сделать выделение и отступы), в общем это настоящий гимор, но я просто уверен что есть стандартные функции (парсеры или еще что нибудь в этом духе), которые упрощают работу в этом направлении. Я искал в направлении microsoft.vsa, microsoft_vsavb, microsoft.vsa.vb.CodeDomProcessor.
Может кто нибудь сталкивался с подобной задачей?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>Вам надо завести топик "Объект скорее жив чем мертв" vs "Объект скорее мертв чем жив"
Это точно

С уважением, Александр.
http://blogs.gotdotnet.ru/personal/AlexKD/

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, vb95, Вы писали:

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

По поводу CodeDom и Emmit то у них есть один недостаток, большое время компиляции и создание для выгрузки скомпилированных сборок если нужно часто и непродолжительное использование скомпилировааных скриптов.

Сходи на
http://gzip.rsdn.ru/Forum/Default.aspx?group=decl

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Живой — значит не собрали (и без разницы, есть сильная ли ссылка или слабая). Не живой — значит ObjectDisposedException.

VD>Не, батенька. Или живой, или нет. Если объект не достижим, то он мертв.

Именно. Но объект, имеющий на себя слабые ссылки, достижим.

VD>А ObjectDisposedException тут вообще не причем. Это вообще чисто логическое исключение.

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

VD>Если уж говорить о финализируемых объектах, то их держит очередь фнализации, так что они живут не менее двух сборок. Но это все частности.

Более того, частности конктретной версии GC. Затачиваться под это не стоит.

VD>Я же говорил, о том, что странно бороться со статическими пермеренными. Ведь проблем можно создать и без них.

Этот вопрос к Тимофей, так как это ты с ним обсуждаешь.

	От:	Аноним
	Дата:	22.01.05 12:36
	Оценка:	-7

	От:	Аноним
	Дата:	23.01.05 12:05
	Оценка:	18 (1) +1

	От:	Аноним
	Дата:	23.01.05 13:58
	Оценка:	-1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	22.01.05 13:21
Оценка:	2 (1) +1

	От:	Poudy
	Дата:	23.01.05 09:20
	Оценка:	18 (1)

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.01.05 15:44
Оценка:

	От:	Воронков Василий
	Дата:	23.01.05 08:39
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	27.01.05 23:02
Оценка:

От:	TK	кывт.рф
Дата:	29.01.05 06:18
Оценка:

От:	Mika Soukhov	Stock#
Дата:	09.02.05 14:44
Оценка: