Здравствуйте, VladD2, Вы писали:
Д>>неопытным солдатам оружия в руки вообще не дают. Только молоток, чтобы добивать упавших монстров Д>>А тех, кто раздает BFG кому попало — под военный трибунал
VD>Не, это опытным оружия не дают. Самые опытные обходятся саперной лопаткой.
Здравствуйте, anvaka, Вы писали:
A>Примерно с какого рейтинга (со скольких тысяч оценок) полученного на РСДНе я смогу разговаривать с такими людьми =)?
Да в принципе ни с какого... Он пообщал приложить все усилия для того чтобы приехать в Москву во время WinFX тура, и пока я бегал за пивом, Андрюха уболтал его прийти после выступления на встречу rsdn-овской юзер группы, чтобы пообщаться в более неформальной обстановке.
Так что, надо всего лишь ходить на встречи RSDN UG...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, VladD2, Вы писали:
VD>>Осталось придумть "как?"
Д>IDE всё равно ведь надо строить дерево кода, чтобы рефакторинг работал. Нет особой проблемы добавлять в это дерево код, которого нет в исходнике в явном виде, потому что он порождается макросом. То есть при парсинге кода, вероятно, нужно будет исполнять код встреченных в нем макросов и полученные результаты помещать в дерево. И помечать эти узлы специальным образом.
Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)? И не получится ли так, что использовав ("засветив" ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Здравствуйте, Cyberax, Вы писали:
C>А где о них объявления бывают?
Как правило в форуме UG, и совершенно точно на сайте UG (http://rsdn.gotdotnet.ru), но он сейчас валяется, обещают что поднимут к двум часам дня. Там же темы докладов, и если зарегистрироваться, то можно голосовать и получать уведомления по почте...
Здравствуйте, prVovik, Вы писали:
V>Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)?
А деваться все равно особо и некуда... других нормальных вариантов я не вижу. А у С++ другие проблемы — переусложненность и неоднозначность синтаксиса, в основном. Производительность среди них далеко не самая важная.
V>И не получится ли так, что использовав ("засветив" ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Здравствуйте, VladD2, Вы писали:
AVK>>А как в Nemerle эти проверки добавить? Чтобы не новый AST генерить, а контроллировать существующий?
VD>Это можно. Только вопрос расплывчатый.
Ну хорошо, более конкретно. Предположим нужно гарантировать отсутствие ключевых слов, не входящих в заранее заданный список.
Здравствуйте, VladD2, Вы писали:
VD>Тут нужно определить, что ты считашь опасными консрукциями (для начала). В Немерле ансэйфа вообще нет.
Ансейф ерунда. Ключик убрал и никакого ансейфа. Я имею ввиду другое — отсутствие конструкций навроде шаблонов С++, которые способны с благими намерениями сделать код нечитаемым.
VD>Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0.
Здравствуйте, Дарней, Вы писали:
V>>Согласен, но не появятся ли проблемы с производительностью такого рефакторинга (в С++ препроцессор как раз вышел боком для рефакторинг примочек)?
Д>А деваться все равно особо и некуда... других нормальных вариантов я не вижу. А у С++ другие проблемы — переусложненность и неоднозначность синтаксиса, в основном. Производительность среди них далеко не самая важная.
Может быть... Но компиляторы С++ и рефакторинг тулзы для него отличаются сильной тормознутостью. И не в первую очередь из-за препроцессора.
V>>И не получится ли так, что использовав ("засветив" Image ) в каком-то месте единожды одн из сильносвязанных классов в макросе, этот класс становится недоступным для рефакторнга?
Д>не совсем понял... можешь пояснить?
Допустим, у нас есть класс А, котогрый активно используется в крупном проекте. Есть Вася, помошник третьего заместителя стажера-программиста, который где-то далеко-далеко, глубоко-глубоко сгенерировал с помощью макроса безобидный с виду прокси-класс для класса "А". Вроде бы как это никого не должно было бы никого коснуться, но Самый Главный Программист очень удивиться, когда попытается переименовать какой-нибудь метод класса "А". Он не сможет этого сделать из-за использования где-то Васей макроса. Таким образом, сигнатуры элементов класса "А" очень легко и "прозрачно" блокируются и становятся недоступными для автоматического рефакторинга.
Здравствуйте, prVovik, Вы писали:
V>Допустим, у нас есть класс А, котогрый активно используется в крупном проекте. Есть Вася, помошник третьего заместителя стажера-программиста, который где-то далеко-далеко, глубоко-глубоко сгенерировал с помощью макроса безобидный с виду прокси-класс для класса "А". Вроде бы как это никого не должно было бы никого коснуться, но Самый Главный Программист очень удивиться, когда попытается переименовать какой-нибудь метод класса "А". Он не сможет этого сделать из-за использования где-то Васей макроса. Таким образом, сигнатуры элементов класса "А" очень легко и "прозрачно" блокируются и становятся недоступными для автоматического рефакторинга.
да, это уже проблема.... надо думать
хотя, по хорошему, далеко не все макросы производят код, который должен референситься в явном виде снаружи
Здравствуйте, Дарней, Вы писали:
Д>хотя, по хорошему, далеко не все макросы производят код, который должен референситься в явном виде снаружи
Ну не скажи... Реализация многих паттернов потребует таких ссылок.
Здравствуйте, Дарней, Вы писали:
Д>IDE всё равно ведь надо строить дерево кода, чтобы рефакторинг работал. Нет особой проблемы добавлять в это дерево код, которого нет в исходнике в явном виде, потому что он порождается макросом. То есть при парсинге кода, вероятно, нужно будет исполнять код встреченных в нем макросов и полученные результаты помещать в дерево. И помечать эти узлы специальным образом.
Исправлять прийдется исходный код. Так что прийдется построить четкое соотвествие между "раскрытым" кодом и исходным. Что, как мне кажется, просто так сделать не выйдет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Может быть... Но компиляторы С++ и рефакторинг тулзы для него отличаются сильной тормознутостью. И не в первую очередь из-за препроцессора.
Рефакторинг-тулзов для Немерла нет. Но его компилятор работает довольно быстро. Так что есть надежда, что со скоростью все будет ОК.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну хорошо, более конкретно. Предположим нужно гарантировать отсутствие ключевых слов, не входящих в заранее заданный список.
Это обеспечить не сложно. Создать метаатрибут который в самом начале пробежится по всем типам и поищет определения переменных по некоторому паттерну.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ансейф ерунда. Ключик убрал и никакого ансейфа.
Хм. А тебе не кажется, что такой же аргумент можно применить и к тем же макросам?
AVK> Я имею ввиду другое — отсутствие конструкций навроде шаблонов С++, которые способны с благими намерениями сделать код нечитаемым.
Макросы С++ создают проблемы не сами по себе, а своей убогостью. В них нет средств контроля происходящего (они работают с текстом). Они не гигееничны (легко сделать трудный в понимании конфликт). И они переопределяемы (что сбивает с толку).
VD>>Но ты то вроде о сложности говорил? C# 3.0 несомннено сложнее C# 1.0.
AVK>Нет, я говорил не о сложности.
Тогда о чем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мы уже победили, просто это еще не так заметно...
