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

MT>Если не жалко скинь книжку (или ссылку) мне на mchashchin@imsmaxims.com. Буду очень признателен.


Нет времени искать ссылу, держи книгу на мыло.

Ожидаю начала проекта и готов участвовать.

Здравствуйте Аноним,

А>Ссылу надо искать Подожди немного, если не найду ссылу (я ее подсмотрел на www.soft-forum.ru), кину книгу на мыло (1.5м)

Коллеги, поделитесь сабжем плз.

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

ND>Здравствуйте Аноним,

А>>Ссылу надо искать :( Подожди немного, если не найду ссылу (я ее подсмотрел на www.soft-forum.ru), кину книгу на мыло (1.5м)

ND>Коллеги, поделитесь сабжем плз.

Хорошо, и тебе вышлю

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

А>Мона, в принципе, было бы написать с нуля шарповый компилер, но это сильно громоздкая задача, никто, скорее всего, не возьмется

Так исходники Шарпового компилятора уже почти месяц как валяются на сайте MS (http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml). Так, что остается только дописать деструкторы, шаблоны, агрегацию и все остальное...

Кстати, MS-ресерчь во времена бэты 2 даже вроде создали вариант C#-компиялтора поддерживающего шаблоны (сам не видел).

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

MT>У меня есть идеи и некие наработки в области аспектно-ориентированного программирования. Так что было бы не плохо и аспектную ориентацию туда прикрутить. Получиться что-то вроде Aspect C# (по аналогии с Aspect Java). Если есть желание я могу Влада и IT попинать насчёт открытия проекта.

Места на сайте достаточно. Главное, чтобы люди заинтерисованные нашлись.

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

IT>...но вот множественное наследование вряд ли. Его должен поддерживать CLR. К тому же надо помнить о том, что всё что пишется на одном языке должно быть запросто доступно в других.

Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
{
   [ImplementInterface]
   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

   [ImplementInterface]
   ISomeInterface1 Itf2;

   SomeBaseCalss(bool bCondition)
   {
      if(bCondition)
         Itf2 = new ISomeInterface1ImplVer1();
      else
         Itf2 = new ISomeInterface1ImplVer2();
   }
}

Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

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

IVNС>5)собрать всю литературу (у меня уже кой-какая подборочка есть !, по МСИЛ тоже )

А не хочешь обнародовать информацию по MSIL. В виде статейки конечно... Думаю, народу было бы интересно.

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

IVNС>Что убыстряет — это точно, а вот как-нить поборороть sealed — хотелось бы

А вот я думаю, что в большинстве случаев sealed ускорения не даст. Ну, а побороть можно все что хочешь если есть исходники. Дизасемблер для MSIL уже сделали. Пока, что кривенький, но работает.

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

А>я тоже эту статью видел, дальше этого пока не пошло. А M$, хотя и сделал конвертор в J#, пока еще далек от победы, так что это может нам на руку сыграть

На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта. В том проекте ведь подразумевалось изменить MSIL. К тму же при этом пришлось бы переписывать все базовые библиотеки. Иначе полезность шаблонов сильно уменьшится. Ведь производительность сильно страдает от универсальных контейнерных классов основанных на object.

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


VD>Так исходники Шарпового компилятора уже почти месяц как валяются на сайте MS (http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml). Так, что остается только дописать деструкторы, шаблоны, агрегацию и все остальное... :)

VD>Кстати, MS-ресерчь во времена бэты 2 даже вроде создали вариант C#-компиялтора поддерживающего шаблоны (сам не видел).

Да, это и есть "ротор". Я уже скачал и даже скомпилял :) Исходники, из-за того, что выполнены в кроссплатформенном виде, выглядят несколько некрасиво, но другого у нас нет, так что и это сгодится.

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

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

IVNС>>5)собрать всю литературу (у меня уже кой-какая подборочка есть !, по МСИЛ тоже )

VD>А не хочешь обнародовать информацию по MSIL. В виде статейки конечно... Думаю, народу было бы интересно.

Пока обещать ничего не буду, ладно ? Надо бы довести до ума C## :)
А вот книгу по МСИЛ могу куда-нить на ваш сайт закинуть, чтоб все могли скачать

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

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

IVNС>>Что убыстряет — это точно, а вот как-нить поборороть sealed — хотелось бы

VD>А вот я думаю, что в большинстве случаев sealed ускорения не даст. Ну, а побороть можно все что хочешь если есть исходники. :) Дизасемблер для MSIL уже сделали. Пока, что кривенький, но работает.

Угу :) Хотя, это просто так не получится :(

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

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

VD>На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта.

Интересно, получит ли это дальнейшее развитие ?

VD>В том проекте ведь подразумевалось изменить MSIL.
К тму же при этом пришлось бы переписывать все базовые библиотеки. Иначе полезность шаблонов сильно уменьшится. Ведь производительность сильно страдает от универсальных контейнерных классов основанных на object.

Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.

Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?
И таких неприятных мелочей много.

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

VD>Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

VD>

VD>class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
VD>{
VD>   [ImplementInterface]
VD>   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

VD>   [ImplementInterface]
VD>   ISomeInterface1 Itf2;

VD>   SomeBaseCalss(bool bCondition)
VD>   {
VD>      if(bCondition)
VD>         Itf2 = new ISomeInterface1ImplVer1();
VD>      else
VD>         Itf2 = new ISomeInterface1ImplVer2();
VD>   }
VD>}
VD>

VD>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

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

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

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

VD>>Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

VD>>

VD>>class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
VD>>{
VD>>   [ImplementInterface]
VD>>   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

VD>>   [ImplementInterface]
VD>>   ISomeInterface1 Itf2;

VD>>   SomeBaseCalss(bool bCondition)
VD>>   {
VD>>      if(bCondition)
VD>>         Itf2 = new ISomeInterface1ImplVer1();
VD>>      else
VD>>         Itf2 = new ISomeInterface1ImplVer2();
VD>>   }
VD>>}
VD>>

VD>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

А>Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

ImplementInterface- это у него мечты о светлом будущем.
Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.
Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса,которая еще не известна во время компиляции (неизвестно даже виртуальные там методы или нет), здесь прийдется попыхтеть чтобы реализовать без глюков. Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.

Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.
Хотелось бы чтобы появилось динамическое связывание.
Хотя в CLR оно есть а в C# его нет.

Чтобы в C# динамически подключиться к assembly нужно шаманить в таком направлении

Assembly a=Assembly.LoadFrom(assemblyPathName);
Type type=a.GetTypes()[0];
MethodInfo methodInf=type.GetMethod(codeName);
object[] params=...
...//проверяем соответствие типов в params и в methodInf
methodInf.Invoke(null,params);

А хотелось бы что то наподобии:

Type type= ...GetTypes....
runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать
obj.Method(param);

Можно было бы сделать такой тип runtime_type из которого можно вызывать любые методы с любыми параметрами, а проверки типов и существования методов только во время runtime. Другими словами вариант с Invoke но гораздо меньше мусора в коде. И существовал бы такой тип вместе с остальными и никому бы не мешал (ни чего бы переделывать бы не пришлось).

В .NET Васике есть же такое динамическое связывание, почему бы в C# не сделать, как альтернативу остальным тимам.

Может это не так часто и нужно, но я уже столкнулся с такой задачей в которой это необходимо.

VD>>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

SS>ImplementInterface- это у него мечты о светлом будущем.

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

SS> Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.
SS> Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса,которая еще не известна во время компиляции (неизвестно даже виртуальные там методы или нет), здесь прийдется попыхтеть чтобы реализовать без глюков. Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.

По-моему, это тупиковый путь. во-первых, отсутствуют проверки на этапе компиляции. Во-вторых, атрибуты придется разгребать в реалтайме и на основании этого генерить код. Это жутко геморройно и некрасиво, а ведь наша задача — получить красивую реализацию ! Уж лучше использовать обычную агрегацию, так хоть, напремер, не вызовешь метод, которого нет :) — не скомпиляется.

SS> Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.
SS>Хотелось бы чтобы появилось динамическое связывание.
SS>Хотя в CLR оно есть а в C# его нет.

SS>Чтобы в C# динамически подключиться к assembly нужно шаманить в таком направлении

SS>

SS>Assembly a=Assembly.LoadFrom(assemblyPathName);
SS>Type type=a.GetTypes()[0];
SS>MethodInfo methodInf=type.GetMethod(codeName);
SS>object[] params=...
SS>...//проверяем соответствие типов в params и в methodInf
SS>methodInf.Invoke(null,params);
SS>

SS>А хотелось бы что то наподобии:

SS>

SS>Type type= ...GetTypes....
SS>runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать

Можно создать экземпляр объекта с вызовом конструктора с помощью Activator.CreateInstance(Type _Type, object[] param)
param - параметры конструктора (выбирается подходящий)

SS>obj.Method(param);
SS>

Так не получится — не скомпиляется. Но вот типа такого — реально:
obj.Methods["Method"](param);


SS>Можно было бы сделать такой тип runtime_type из которого можно вызывать любые методы с любыми параметрами, а проверки типов и существования методов только во время runtime. Другими словами вариант с Invoke но гораздо меньше мусора в коде. И существовал бы такой тип вместе с остальными и никому бы не мешал (ни чего бы переделывать бы не пришлось).

SS>В .NET Васике есть же такое динамическое связывание, почему бы в C# не сделать, как альтернативу остальным тимам.

SS>Может это не так часто и нужно, но я уже столкнулся с такой задачей в которой это необходимо.

Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять :)
Достаточно написать класс, который расковыривает в реатайме любой тип.

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

А>Угу Хотя, это просто так не получится

Дык, а мы легких путей не ищем.

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

VD>>На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта.

А>Интересно, получит ли это дальнейшее развитие ?

После того как о шаблонах заговорили в Sun, я думаю, что у MS просто не будет выбора. Хотя они очень разжирели и стали малость глухи к мольбам народа. В конференциях MS часто болтаются люди из команд работающих в MS над языками и .Net можно попробывать замутить там мат. Но это нужно делать на нормальном английском (коим я не обладаю) и предварительно сформулировав и обосновав все пренензии и предложения.

А>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.

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

А>Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList

Вот об этом и речь. Только, я бы сформулировал так: Динамические массивы доступны только для общего класса object, что рпиводит к тормозам при использовании value-типов и невозможности проверок на стадии компиляции из-за ненужного здесь полиморфизма. С шаблонами можно было бы написать эффективную реализацию этого и других контейнерных классов.

А>, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?

Потому, что в природе не существует алгоритмов realloc-а. При realloc-е просто занимается новый массив, данные копируются, а старый освобождается. Такой realloc я и сам за пять минут сворганю. Только он будет еще более медленный чем ArrayList (при условии частого изменения размера массива).

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

VD>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

А>Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

Это все мечты, которые можно было бы воплотить в жизнь.

Общий смысл такой. Этот атрибут указывает компилятору, что реализацию интерфейса присвоеную в переменную помечанную этим атрибутом (или чем угодно еще) нужно использовать для реализации интерфейса (который должен к тому же быть перечислен в списке наследования).

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