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

S>Наверное лучше иметь синицу в руках. Делегаты в Delphi задолго прекрасно себя показывали. Причем преобразовывя процедурный апи в объектный.
S>Понятно что ФП маячило очень далеко и нужно было показывать скорости сопоставимые с нативными.
Бу-га-га.
Эффективно реализовать функциональный тип много проще чем мультикаст делегат.
Вспомни скорость работы делегатов.
А вызов функционального типа легко сводится к виртуальному вызову.
Собственно всякие там окамлы это прекрасно демонстрируют.

S>Дженерики при неотложной необходимости появились несразу.
Это еще одна серьезная баранка Хейлсбергу и все комманде.

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

EC>>По поводу ref и out параметров точно не скажу — не уверен, что они есть.
S>По идее должны для совместимости делегатов. Можно попробовать проверить через FuncConvert.ToFastFunc
Есть Ref<A>.
EC>>Насчёт возвращаемых параметров в виде FastFunc<T, U> не совсем понял — просто FastFunc<T, U>'ом будет параметризован другой FastFunc<T, U>.
S>Это к вопросу возврата множества параметров по аналогии с выводом из одного множества параметров. Раз есть возможность в одну сторону тогда же она есть и в другую
Множества через кортежи возвращают.

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

WH>А вызов функционального типа легко сводится к виртуальному вызову.
WH>Собственно всякие там окамлы это прекрасно демонстрируют.
И Nemerle!

S>>Дженерики при неотложной необходимости появились несразу.
WH>Это еще одна серьезная баранка Хейлсбергу и все комманде.
Ну уж! То-то шарп на белом коне.

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

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

S>>Наверное лучше иметь синицу в руках. Делегаты в Delphi задолго прекрасно себя показывали. Причем преобразовывя процедурный апи в объектный.
S>>Понятно что ФП маячило очень далеко и нужно было показывать скорости сопоставимые с нативными.
WH>Бу-га-га.
WH>Эффективно реализовать функциональный тип много проще чем мультикаст делегат.
WH>Вспомни скорость работы делегатов.
WH>А вызов функционального типа легко сводится к виртуальному вызову.
WH>Собственно всякие там окамлы это прекрасно демонстрируют.
В С# ксати многое растет из Delphi во всяком случае компонентность (а as вызывает исключение, а как без метаклассов жить вообще не понимаю). Там два вида делегата ссылка на статический метод и структура содержащая ещё ссылку на объект
и скорость вызова быстрее чем виртуального метода. в Net ошибка введения мультикаст делегата и взятие его за базовый класс,
просто по аналогии с дельфевыми эвентами видно поздно пришло решение о множественном вызове и было принято не совсем верное решение, хотя и универсальное.
Так или иначе функциональный тип должен быть классом, наследоваться от единого предка,иметь MethodInfo для рефлексии,который должен быть введен в System,
Смотря на FastFunc этого тогда сделать было сложно.
S>>Дженерики при неотложной необходимости появились несразу.
Но ведь никто не мешает ввести такой тип сейчас, и пусть сосуществуют с делегатами паралельно
WH>Это еще одна серьезная баранка Хейлсбергу и все комманде.
Причем делегаты за этой баранкой смело можно и не замечать. Но дальнейшее развития как языка так и программистского сообщества весьма радует.
А я вот в 1С погряз и все эти вкусности мимо меня проходят, но и там можно многое сделать. Главное было бы,что решать. А так под каждую задачу свой инструмент, для многих вполне за глаза хватает и нынешних возможностей. Поэтому ты находишься далеко за тремя сигмами от среднего в правую сторону

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

WH>Сарказм не уместен.
WH>Я показал два примера не знания основ.
Могли быть какие-нибудь другие причины сделать так, типа какой-нибудь дурацкой совместимости о которых мы не знаем.
Потому как дико представить, что такие люди не были знакомы с ML например.

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

WH>Бу-га-га.
WH>Эффективно реализовать функциональный тип много проще чем мультикаст делегат.
WH>Вспомни скорость работы делегатов.
WH>А вызов функционального типа легко сводится к виртуальному вызову.
WH>Собственно всякие там окамлы это прекрасно демонстрируют.

Только вот непонятно как это реализовать через виртуальные вызовы, сохранив компонентность (так чтобы делегаты, созданные в сборке А можно было вызывать в сборке Б при том, что обе сборки ничего друг о друге не знают и не используют третью библиотеку с описанием типа делегата)?

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

EC>Могли быть какие-нибудь другие причины сделать так, типа какой-нибудь дурацкой совместимости о которых мы не знаем.
Какая к черту совместимость при проектировании платформы с нуля?!

EC>Потому как дико представить, что такие люди не были знакомы с ML например.
У тебя есть другие варианты?

А как насчет фундаментальных правил:
1)Не хардкодить. Тем более при проектировании модели.
2)Неумения отделять модель от представления?

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

S> В С# ксати многое растет из Delphi во всяком случае компонентность (а as вызывает исключение, а как без метаклассов жить вообще не понимаю). Там два вида делегата ссылка на статический метод и структура содержащая ещё ссылку на объект и скорость вызова быстрее чем виртуального метода. в Net ошибка введения мультикаст делегата и взятие его за базовый класс, просто по аналогии с дельфевыми эвентами видно поздно пришло решение о множественном вызове и было принято не совсем верное решение, хотя и универсальное.
Не находишь что это не стыкуется с тезисом о том что он смотрит по сторонам.

S>Так или иначе функциональный тип должен быть классом, наследоваться от единого предка,иметь MethodInfo для рефлексии,который должен быть введен в System, Смотря на FastFunc этого тогда сделать было сложно.
Ну это сделать никто не мешал при любом раскладе.

S>Но ведь никто не мешает ввести такой тип сейчас, и пусть сосуществуют с делегатами паралельно
Ну так до сих пор не ввели.
Хотя при реализации генериков сильно пилили рантайм.

S>Причем делегаты за этой баранкой смело можно и не замечать.
Нельзя. Особенно если принять то что Хейлсберг таки смотрел по сторонам...

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

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

V>Только вот непонятно как это реализовать через виртуальные вызовы, сохранив компонентность (так чтобы делегаты, созданные в сборке А можно было вызывать в сборке Б при том, что обе сборки ничего друг о друге не знают и не используют третью библиотеку с описанием типа делегата)?

Очевидно как — они будут использовать общую сборку. Аналоги System.Core есть и у фшарпа и у немерля.
Вот сделать анонимные типы шарпа глобально доступными — тут уже общей сборкой не отделаешься, увы, тут надо дорабатывать CLR. А мужики в CLR Team настолько суровы ...

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

AVK>Очевидно как — они будут использовать общую сборку. Аналоги System.Core есть и у фшарпа и у немерля.

А как поможет общая системная сборка при условии, что у нас нет дженериков?

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

WH>Какая к черту совместимость при проектировании платформы с нуля?!
Эта платформа должна интероперировать много с чем: COM, Plain C dlls, etc.
И артефакты этого дела много откуда торчат.
И я думаю они учитывали особенности языков, которые предполагалось реализовать для неё (типа C++/CLI).
Уверен, что это тоже оказало влияние на дизайн рантайма.ё
Может и с делегатами нечто подобное было.
EC>>Потому как дико представить, что такие люди не были знакомы с ML например.
WH>У тебя есть другие варианты?
Вариант, что пацаны с рсдн лучше знают как проектировать языки и виртуальные машины мне видится ещё менее реалистичным.

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

AVK>>Очевидно как — они будут использовать общую сборку. Аналоги System.Core есть и у фшарпа и у немерля.

V>А как поможет общая системная сборка при условии, что у нас нет дженериков?

Если нет — никак. Но они же у нас есть.

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

AVK>Если нет — никак. Но они же у нас есть.

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

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

WH>>Какая к черту совместимость при проектировании платформы с нуля?!
EC>Эта платформа должна интероперировать много с чем: COM, Plain C dlls, etc.
EC>И артефакты этого дела много откуда торчат.
Бу-га-га.
Давай придумай куда к интеропу можно прицепить опкоды Add, Mul, Ldc_I4_0,...
Хоть что-то похожее на реальность.

Пока я вижу только непонимание азов проектирования программного обеспечения вобще и ВМ в частности.

EC>И я думаю они учитывали особенности языков, которые предполагалось реализовать для неё (типа C++/CLI).
Тоже не аргумент ни разу.
Компилятору абсолютно все равно что сгенерить. Опкод Add или вызов функции int.Add(int) -> int.

EC>Уверен, что это тоже оказало влияние на дизайн рантайма.ё
EC>Может и с делегатами нечто подобное было.
Придумай хоть что-то похожее на реальность.

EC>Вариант, что пацаны с рсдн лучше знают как проектировать языки и виртуальные машины мне видится ещё менее реалистичным.
Что? Засчитываем слив сразу или таки найдешь хоть один технический аргумент?

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

V>Только вот непонятно как это реализовать через виртуальные вызовы, сохранив компонентность (так чтобы делегаты, созданные в сборке А можно было вызывать в сборке Б при том, что обе сборки ничего друг о друге не знают и не используют третью библиотеку с описанием типа делегата)?
Я еще раз провторю магические слова: Разработка виртуальной машины с нуля.
Все что нужно это чтобы ВМ считала делегаты с одной сигнатурой из разных сборок за один тип. И все!
Или еще лучше чтобы ВМ считала вобще все типы с одинаковой структурой из разных сборок за один тип.
Тогда и с анонимными типами проблем бы небыло.

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

V>Вооот, но речь то шла, что мол Хейлсберг нишиша в языках программирования не шарит

Про Хейлсберга и нишиша я пробробнейшим образом отписался в соседнем топике. Пока что добавить к этому мне нечего.

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

WH>Я еще раз провторю магические слова: Разработка виртуальной машины с нуля.
WH>Все что нужно это чтобы ВМ считала делегаты с одной сигнатурой из разных сборок за один тип. И все!

За какой именно тип: за тот, что в первой сборке описан, или за тот, что во второй?

WH>Или еще лучше чтобы ВМ считала вобще все типы с одинаковой структурой из разных сборок за один тип.
WH>Тогда и с анонимными типами проблем бы небыло.

Вот, это уже теплее. То есть для того, чтобы сделать "правильные" делегаты, надо было сначала ввести структурные типы, причем не вместо обычных, а в дополнение к ним с некислой переработкой ВМ. При этом надо было ещё сделать обратную совместимость с джава-образной виртуальной машиной, так как перед разработчиками стояла задача реализации и поддержки джавы на дотнетовской виртуальной машине. То есть не всё так просто, как на первый взгляд.

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

V>За какой именно тип: за тот, что в первой сборке описан, или за тот, что во второй?
До лампочки.
Они абсолютно одинаковые.

V>Вот, это уже теплее. То есть для того, чтобы сделать "правильные" делегаты, надо было сначала ввести структурные типы, причем не вместо обычных, а в дополнение к ним с некислой переработкой ВМ.
Какая блин переработка? Они ВМ писали с нуля! Сколько еще раз это повторить?
Да и вся сложность добавить хешьтаблицу. Где тут некислость?
Более того можно вобще не париться, а ввести это правило для всех типов.

V>При этом надо было ещё сделать обратную совместимость с джава-образной виртуальной машиной, так как перед разработчиками стояла задача реализации и поддержки джавы на дотнетовской виртуальной машине. То есть не всё так просто, как на первый взгляд.
JVM и CLR по любому между собой не совместимы.
А если делать более умно то получится суперсет жабы.
Да он и так в общем получился.
Ни value типов ни делегатов в жабе нет.
А транслировать сабсет в суперсет задача тривиальная.
Так что опять мимо.

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

WH>Я еще раз провторю магические слова: Разработка виртуальной машины с нуля.

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

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

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

А вы так настойчиво ни одной фразы по делу не сказали, все прикапываетесь ко всем.
Еще раз, не обязательно быть курицей, чтобы спорить о вкусе яичницы. К тому же ошибки всегда хорошо видны со стороны, особенно если ты разбираешься во внутренностях не только одной ВМ. Я много где уже слышал со слов разработчиков команды CLR фразы типа "я не в курсе как это сделано в JVM, я не специалист по Java". Такие фразы от разработчиков ВМ у меня всегда улыбку странную на лице вызывают