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

V>Просто сама идея автоматизированного рефакторинга не дружит с макросами и фокусами с АСТ, так как тут рафакторинг тулза помимо того, что должна уметь исполнять хитроумные и навороченные макросы (простые нам не нужны ), что само по себе не просто, но и заниматься реинжинирингом, что в общем случае сделать невозможно. То есть тут на карте либо автоматизированный рефакторинг, либо навороченные макросы. Выбрали, похоже, первое (имхо, правильно сделали). Все, конечно, ИМХО.

Лучшеб выбрали макросы, а если сами не могут придумать как их отрефакторить, то найдутся те, кто сможет. Возможно, JetBrains, а возможно кто еще. Да и кто вам сказал, что действительно выбор между двух "либо". Почему не оставить автоматизированный рефакторинг в том виде в каком он есть сейчас, а для макросов его просто не добавлять.
И вообще, помимо возможностей описания макросов, можно добавить возможности декларативного описания действий этих макросов для средств рефакторинга.

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

ie>Лучшеб выбрали макросы, а если сами не могут придумать как их отрефакторить, то найдутся те, кто сможет. Возможно, JetBrains, а возможно кто еще. Да и кто вам сказал, что действительно выбор между двух "либо". Почему не оставить автоматизированный рефакторинг в том виде в каком он есть сейчас, а для макросов его просто не добавлять.
ie>И вообще, помимо возможностей описания макросов, можно добавить возможности декларативного описания действий этих макросов для средств рефакторинга.
дык сначала наверное надо придумать как это все провернуть, а потом делать. А то получится как обычно, понапихают фич, потом через годик репу почешут, и поймут, что все надо было делать не так, а потому ждите C#15, который несовместим с предыдущими версиями (несовместим — это в лучшем случае. В худшем будет C# => С++ )

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

IT>Больше. Но это "больше" не является той критической массой из-за которой метапрограммирование нужно запретить как вселенское зло.

А вот это уже фик его знает. Пока не будет наработана база реальных решений вряд ли кто точно сможет на это ответить. Когда речь идет о экспериментальных языках, я обеими руками за. Я сам тут, на rsdn, чуть ли не самый первый ратовал за кодогенерацию, в том числе и совмещенную с рукописными исходниками. Но когда тут говорят, что нужно выкинуть C# и срочно переходить на Nemerle, то я, мягко говоря, подобный экстремизм не приемлю. Потому как, даже если идея в целом правильная, понадобится пройтись по тачке грабель, прежде чем из нее получится что то путное. Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.

IT> К тому же несколько макросов расширяющих синтаксис — это капля в море по сравненю с объёмом кода, который нужно будет постигнуть девелоперу только что пришёдшему на проект. Но вот эти самые макросы могут позволить существенно уменьшить код, с которым этому девелоперу придётся столкнуться. Так что всё зависит от того как на это посметреть.

Опять же — совершенно неизвестно куда эта дорожка может завести. Страуструп с шаблонами тоже наверное не думал, что их кто то для генерации кода использовать будет.

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

Я сам таких примеров понарассказать могу вагон. И у меня сейчас закрадывается мысль отказаться от C# в качестве языка для прикладного кода из-за того что он слишком много позволяет, а тут Nemerle предлагается .

IT>Метапрограммирование — шаг в том же направлении. Не больше и не меньше.

Шаг то он однозначно. А вот насчет направления я не уверен. Тут как с болотом — пока не шагнешь, не ощутишь в какое дерьмо вляпался. Я конечно верю, что некоторые, с особым обонянием, способны ощутить запах вышеозначенной субстанции на расстоянии, не взирая на покрывающую его болотную жижу, но рядом всегда есть толпа других, которые реально ничего не чувствуют, а только делают вид. А уж если меня начинают убеждать, что куда не плюнь, везде розами благоухает (это на болоте то!), то я совсем в смущение вхожу, потому как с детства помню, чем закончился ботанический эксперимент товарища Буратины (ровно как и общение его с болотом).

IT>Для C++ рефакторинга вообще пока не существует и народ как-то живёт.

(Слово на букву Х) живет он, однако. Я так не хочу.

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

Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.

AVK>>Если говорить о прикладных DSL, то там крайне важен жесточайший контроль за прикладным кодом. В случае прикладных декларативных DSL мне понятны пути, как этого достичь. А в случае Nemerle?

IT>Запретить создание и модификацию сборок с макросами инженерам, которым не положено это делать по должности.

И регулярно code review делать?

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

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

AVK>>Опять непонятно. Плиз, открой спецификацию C# 3.0 и используй термины оттуда, иначе тебя сложно понимать. expression lambda, которые не statement, это, видимо, что то потрясающее, но мне не известное.
GZ>Занятно. Я тебе уже второй раз объясняю терминами взятыми из спецификации либо доков. Ты их читаешь?



GZ>Открываем, спеки от С#3.0, смотрим 23.6(собственно 26.3 Lambda expressions),

Не находишь, что Lambda expression и Expression lambda, это, мягко говоря, не одно и то же? Первое обычно здесь называют просто lambda, а второе это бессмыслица.

GZ> замечаем что лямбда может быть двух типов, lambda c expression body, и lambda c statement body.

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

AVK>>О, последнее предложение ключевой момент.
GZ>И чем собственно они отличаются? Значит для генериков это простительно, а для type inference — это отстой?

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

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

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

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

AVK>>>О, последнее предложение ключевой момент.
GZ>>И чем собственно они отличаются? Значит для генериков это простительно, а для type inference — это отстой?
AVK>Для генериков это происходит по очень примитивному алгоритму, который несложно предсказать, а вот в Nemerle логика может быть весьма непростой для быстрого понимания.
type inference к макросам Nemerle отношения не имеют.

С уважением, Gleb.

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

Д>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.

Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю.

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

GZ>type inference к макросам Nemerle отношения не имеют.

А я где то писал что имеют?

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

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

GZ>>type inference к макросам Nemerle отношения не имеют.
AVK>А я где то писал что имеют?

Ну судя по тому, что я Nemerle вообще не упоминал, ты с разговора на разговор не переключился. Мы обсуждали твое мнение что type reference существенно ухудшают читабельность.

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

GZ>Ну судя по тому, что я Nemerle вообще не упоминал, ты с разговора на разговор не переключился. Мы обсуждали твое мнение что type reference существенно ухудшают читабельность.

type inference?
Цитирую:

AVK>>>и type inference
GZ>>Тоже Влад тут уже возмущался. Недоделанный какой-то.

Ссылка на возмущения Влада для пояснения откуда взялся Nemerle нужна?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно.
Рефакторить то можно, трудно сделать так, чтобы отрефакторенный код после рефакторинга не потерял работоспособность. Тут нужны специальные "обрезанные" макросы, которые не могут ничего знать об объектах (типах, методах и пр.), с которыми они будут работать, эти макросы должны быть в некоторой степени контекстно независимыми. Проблема в том, что на таких "обрезанных" макросах нельзя будет реализовать даже такю простейшую с точки зрения метопрограммирования вещь, как параметрические типы (шаблоны классов в "классическом" понимании, дженерики (если забыть про их компонентность)). Может быть, я ошибаюсь, хз.

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

AVK>Ссылка на возмущения Влада для пояснения откуда взялся Nemerle нужна?
Нет не нужна. Я ее помню. Там было достаточно много рекламы Nemerle, и мало того, что и другие языки прекрасно поддерживают вывод типов.

А это что?

AVK>>И слава богу. Вывод типов по выражениям в конце метода резко снизит читаемость.
GZ>Не соглашусь. Во многом эта ситуация похожа на ситуацию с generic. Мы не знаем что это за тип, нас волнует только логика обработки. А ежели где напакостничили, то компилятор нам об этом сообщит. Или надо будет смотреть по коду что это за тип.

Собственно это и есть мое несогласие.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

Д>>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.

ANS>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю.
Ну или, как тут уже упоминал Влад, порождающие макросы. Представь: макрос порождает класс, который затем "ручками" используется в коде. Мы пытаемся поменять, например, имя какого-нибудь метода. Получаем две проблемы:

1) Не главная проблема. Рефакторинг тулза не может знать, что надо подкрутить в макросе, чтобы все заработало. Она вообще не будет знать, что существует некий макрос, который потом, т.е. после работы рефактор тулзы сгенерирует соответствующий класс. Как побочный эффект, во всех местах, где будет использоваться этот класс, мы увидели бы от решарпера "красные полоски", сообщающие о синтаксической ошибке. Но это не главное. В одном месте не обломится и ручками поправить.

2) Главная проблема. Рефакторинг тулза не будет знать, что все случаи использования методов класса принадлежат, на самом деле, одному классу. То есть если метод "А" генерируемого класса использовался в программе 300 раз, то после изменения его сигнатуры в макросе, нам ручками предстоит поменять вызов этого метода в программе в 300 местах. А теперь представь, что получится, если придется рефакторить крупную систему, которую писали "кул хацкеры". Проще ее будет заново переписать, чем рефакторить

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

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

V>>Неужели, в немерле есть отладчик времени компиляции?

VD>Ага! И еще какая!!! Код макросов — это код на Немерле. И этим все сказано! Так что все приемы программирования и отладки идентичны как в метакоде, так и в обычном коде.

С той лишь разницей, что для того, чтобы пойматься на брекпоинте в теле макроса, надо как-то приаттачиваться к процессу компилятора "на лету"
Реализуемо, но реализовано пока

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

Д>>>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.

ANS>>Долго читал, но так и не понял в чем проблема. Можно рефакторить либо отдельно код макросов, либо код их использующий, ну либо и то и другое одновременно. А вот как можно рефакторить код, которого не существует (код сгенерённый макросами) я не понимаю.
V>Ну или, как тут уже упоминал Влад, порождающие макросы. Представь: макрос порождает класс, который затем "ручками" используется в коде. Мы пытаемся поменять, например, имя какого-нибудь метода. Получаем две проблемы:

А, понятно понятно. Значит нужно запускать компиляцию после рефакторинга и запрещать оный если есть оно не компилицца.

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

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

IT>>Больше. Но это "больше" не является той критической массой из-за которой метапрограммирование нужно запретить как вселенское зло.

AVK>А вот это уже фик его знает. Пока не будет наработана база реальных решений вряд ли кто точно сможет на это ответить.

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

AVK>Потому как, даже если идея в целом правильная, понадобится пройтись по тачке грабель, прежде чем из нее получится что то путное.

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

AVK>Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.

Я не помню какой была Java. Помню только что религия и высокомерие плюсовика мне тогда не позволяли так низко пасть

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

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

AVK>Я сам таких примеров понарассказать могу вагон. И у меня сейчас закрадывается мысль отказаться от C# в качестве языка для прикладного кода из-за того что он слишком много позволяет, а тут Nemerle предлагается .

Мда... как всё запущено...

AVK>Шаг то он однозначно. А вот насчет направления я не уверен. Тут как с болотом — пока не шагнешь, не ощутишь в какое дерьмо вляпался.

Ну не надо нам тут таких страшилок в качестве аналогий приводить. Всё в Немерле нормально. Нигде там ничего не воняет. Очень красивый и выразительный язык. Даже функциональщину ребятам удалось сделать с человеческим лицом. Тому же C# до него со своими потугами в виде анонимных делегатов ещё как раком (простите мне мой французский) до Парижа.

AVK> Я конечно верю, что некоторые, с особым обонянием, способны ощутить запах вышеозначенной субстанции на расстоянии, не взирая на покрывающую его болотную жижу, но рядом всегда есть толпа других, которые реально ничего не чувствуют, а только делают вид. А уж если меня начинают убеждать, что куда не плюнь, везде розами благоухает (это на болоте то!), то я совсем в смущение вхожу, потому как с детства помню, чем закончился ботанический эксперимент товарища Буратины (ровно как и общение его с болотом).

Ты в детстве слишком много неправильных книжек читал. Буратина же был банальным воришкой. Ты ещё наверное и самый садистский мультик "Ну, погоди!" смотрел?

IT>>Для C++ рефакторинга вообще пока не существует и народ как-то живёт.

AVK>(Слово на букву Х) живет он, однако. Я так не хочу.

И я не хочу так как сейчас живу. Хочу забыть об эмите как о страшном сне.

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

AVK>Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.

Да причём тут LINQ? Речь о том, что MS совсем отмахивается от возможности привнести в язык метапрограммирование. Вот это озадачивает.

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

MS, по-моему, что-то пыталась сделать в предыдущих студиях с помощью ентерпрайз шаблонов. Как эксперимент? Провалился?

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

IT>Реальные решения я тебе несколькими постами ранее продемонстрировал на самой наитипичнейшей задаче.

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

AVK>>Вспомни, к примеру, Java — какой это по началу был уродец, при том что идея управляемой платформы у тебя сейчас вроде как отторжения не вызывает.

IT>Я не помню какой была Java.

Зато я помню. Не приведи господь

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

Зато наверняка есть другие.

IT>Ну не надо нам тут таких страшилок в качестве аналогий приводить.

Это не аналогии, это образные выражения.

AVK>>Надо, кто же спорит. Только ведь у группы LINQ немножко другая задача. Им надо к концу года выкатить рабочий инструмент. А научными проблемами уже MSR занимается.

IT>Да причём тут LINQ?

На заголовок топика посмотри, да?

IT> Речь о том, что MS совсем отмахивается от возможности привнести в язык метапрограммирование. Вот это озадачивает.

Совсем отмахивается в промышленном языке. При этом спонсирует тот самый Nemerle.

IT>MS, по-моему, что-то пыталась сделать в предыдущих студиях с помощью ентерпрайз шаблонов.

Не то. Они на уровне среды это делали, а надо на уровне языка.

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

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

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

Д>Просто не надо рефакторить порожденный макросами код, вот и всё. Сложно, неинтуитивно, да и смысла в этом особого нет.

Простой пример. Макрос Accesor порождающий свойство по полю. Предположим, что мы хотим изменить имя своайства. Что для этого должен сделать рефакторер?

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

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

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

V>2) Главная проблема. Рефакторинг тулза не будет знать, что все случаи использования методов класса принадлежат, на самом деле, одному классу. То есть если метод "А" генерируемого класса использовался в программе 300 раз, то после изменения его сигнатуры в макросе, нам ручками предстоит поменять вызов этого метода в программе в 300 местах. А теперь представь, что получится, если придется рефакторить крупную систему, которую писали "кул хацкеры". Проще ее будет заново переписать, чем рефакторить

Это он знать может. Но первая проблема остается.