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

S>Поскорее бы, а то был щасливым человеком пока не попользовался IntelliJ IDEA и несмотря на мою неприязнь к Java и IDE базированіх на ней пристрастился к таким штукам.

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

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

Y_M>Вопрос будет ли гипотетически компилироваться такой код?
Y_M>

Y_M>void F(readonly TAAA aaa)
Y_M>{
Y_M>  aaa.i=0;
Y_M>  int i=aaa.GetNext();
Y_M>}
Y_M>

TAAA — это ссылочный тип. readonly будет относиться к ссылке, а не к содержимому. Так сейчас сделано в Шарпе. Хотя это уже нужно обсуждать.

Если относить readonly к содержимому объекта, то первый код долже будет выдать ошибку, а второй нет, так как про кишки GetNext() никто не будет знать до реального вызова (она же мжет быть просто в другой сборке).

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

В общем, по началу будет конторолировать только ссылку. Это уже даст приемущества. А там видно будет.

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

D_S>Насколко я понимаю, все ето ляжет только лишь на компайл-тайм. Хотя, конечно... вобщем тут думать надо

Согласен. Причем нам пока не васе предпосылки ясны. Вот если воспроизвести хотя бы то что сделано в Шарпе, то многое станет отчетливо ясно и найдутся обходные пути.

Так что предлагаю до конца года подготовиться, а со следующего года приступить к реализации свого двойника Шарпа.

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

M>Многовато работы — компилятор писать, разве что на весь сайт устроить PR-компанию.

Да не так чтобы очень многь. Есть уже готовые вещи.

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

Да можно было бы вообще взять Моно и не париться. Но ведь он GNU-тый. А я не хочу проблем с лицензиями.

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

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

Да я потихоничку копаюсь. Но времени чтобы это еще и описать у меня нет.

M> Тут нужен какой-то доброволец.

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

M> А вы его за это стимулируйте какими-нибудь невещественными факторами. Ну, там журнал ему бесплатно присылайте, или шапку какую-нибудь с логотипом, прославить посулите на всю страну и т.п.

Это конечно можно.

M>Конечно, SSCLI и Mono на болванку такому кадру тоже слить стоило бы.

Да они вроде в интее доступны. Если тольк с Инетом проблемы...

M>У меня таких знакомых нету. Это уж вы там в RSDN в новостях устройте анонсы. Главное, лести не жалейте! Чтоб качественный target на это дело купился

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

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

VB>Кстати здесь за <b>adding experimental features to the compiler(s) and runtime</b>(правда все это нужно в Роторе делать) даже денег дают.

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

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

VD>Это не окончательный список, да и можно обсудить детали/необходимость предложенных мной фич.

Тогда уж добавь и такую извращенскую фичу (мелочь а приятно):

 int MyProp
{
   onChange
{
  //...OnChange
}
}

Чтоб писать вместо такого, а то лень иногда по клаве стучать, когда таких штук слишком много:

 int _MyProp;
 int MyProp
 {
   get
 {
  return_MyProp;
 }
 set
 {
 _MyProp=value;
 //...OnChange
 }
}

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

S_>Тогда уж добавь и такую извращенскую фичу (мелочь а приятно):


S_>

S_> int MyProp
S_>{
S_>   onChange
S_>{
S_>  //...OnChange
S_>}
S_>}
S_>

Да. Ндобы что-то вроде этого. Но это нужно обдумывать. В общем, нужно отедельно обсуждать фича-лист.

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

IT>>Зачем? Старый плюсовый трюк:

AVK>Понятно. Извращенец

Извращенец — это тот кто пишет на голом Emit. А на MSIL# писать ничем не извращённей чем на просто MSIL

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

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

Так наличие дерева разбора не является прерогативой компилятора.

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

VD>Да. Ндобы что-то вроде этого.

Можно содрать синтаксис из С++/CLI

По сравнению с джеем
Плюсы
1) Заметно более внятный синтаксис метаязыка
2) Значительно больше вещей описывается декларативно. Например построение синтаксического дерева можно осуществить без написания вставок на целевом языке.
3) Результат генерации — классический синтаксический анализатор, осуществляющий разбор методом рекурсивного спуска. Отлаживать такой код довольно просто.
4) Есть готовый кодогенератор и рантайм для шарпа.

Минусы
1) Непонятная задержка при самом первом вызове лексера. С причинами не разбирался.
2) Какой то бардак в шарповском рантайме с case sensitive лексера. При case sensitive = false все равно почему то чувствителен к регистру.
3) Джавовский стиль кода. Т.е. camel notation методов, вместо свойства методы getProperty()/setProperty().
4) Непонятно насколько соответствует готовая грамматика для шарпа стандарту. Слова "Grammar file for cSharp language which supports most part of the cSharp language spec." настораживают. Если most значит не полностью, если не полностью то почему?
5) Рантайм почему то не вызывает никаких событий, хотя сами события наличествуют.

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

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

IT>О! Кстати о птичках. Я тут уже изобрёл MSIL на C#'. Вот кусочек из RFD:

Так и хочется сказать:"Все гениальное просто"

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

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

VD>>Это не окончательный список, да и можно обсудить детали/необходимость предложенных мной фич.

S_>Тогда уж добавь и такую извращенскую фичу (мелочь а приятно):


S_>

S_> int MyProp
S_>{
S_>   onChange
S_>{
S_>  //...OnChange
S_>}
S_>}
S_>

S_>Чтоб писать вместо такого, а то лень иногда по клаве стучать, когда таких штук слишком много:


Да нет, тогда уж атрибутами

[PropertyAccessor("MyProperty")]
int myVariable;


И что бы если нет свойства MyProperty оно автоматически при компиляции появлялось

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


VD>Мне кажется тут нужна все же команда, т.е. несколько увлеченных людей жаждущих извучать и творить. Можно попробовать создать "RSDN Research". И набрать в него членов.

Я б в ресёч пошелЮ пусть меня запишут
На самом деле если будет время, то я с удовольствием

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

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

IT>>>Хачу развитие AOP
IT>>>Сейчас атрибуты можно читать только с помощью рефлекшин всякими интерсепторами. Хочу, чтобы с помощью атрибутов можно было встраивать в методы куски кода.

В>>Полность поддерживаю.

VD>Если реализуем, то о чем я говорю АОР будет самым меньшим, что мы получим.

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

#compile use "myplagin"

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

Но это все мечты, мечты

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

VD>А получить некий C#++ или R[SRN]# давненько хотелось.

Не, лучше C##

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

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

AVK>Так наличие дерева разбора не является прерогативой компилятора.

Это 90% компилятора. Имея полноценный разбор говорить о полумерах вроде препроцессора просто смешно.

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

VD>>А получить некий C#++ или R[SRN]# давненько хотелось.

L>Не, лучше C##

Тоже не плохо. Но произностить тяжело. Си шапр шарп — не звучит.

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

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

О! Классная мысль. Именно так и нужно делать! А подключать фичи можно на базе обычных атрибутов.

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

В>#compile use "myplagin"

Не лучше так:
[module : DsdnCompilerUse(myplagin)]

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



В>Но это все мечты, мечты

Мы раждены чтоб сказку сделать! Одназначко!

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

В>Да нет, тогда уж атрибутами

В>[PropertyAccessor("MyProperty")]
В>int myVariable;

В>И что бы если нет свойства MyProperty оно автоматически при компиляции появлялось

Не, такое точно не годится.