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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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

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

ЗЫ

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

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

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

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

S>

---

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

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

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

VD>>Нчено. И тебя вычичим (с).
S> Переведи!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗЫ

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

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

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

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

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

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

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

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

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

И вас так же.