Здравствуйте, Nikkk2010, Вы писали:
N>Проект Рослин на Lang-NEXT-2012
Я его смотрел. Он, к сожалению, нам мало чем полезен. Весь АПИ закрыт почти полностью. Куча "дружеских" связей между сборками (открывают внутренний доступ друг другу). Плюс ориентация на рефакторинг, а не на макросы (изменение кода во время компиляции).
Плюс, когда я его смотрел (отностильно недавно), он был еще в очень зачаточной стадии. Куча фич языков не поддерживалась.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Nikkk2010, Вы писали:
N>>Проект Рослин на Lang-NEXT-2012
IT>Фиг с ним с квазицитированием, но как они собираются без ПМ код анализировать? Очередная технология для мазохистов?
Когда вышла первая информация о проекте Roslyn — скачал, Reflector на все сборки о посмотрел код, который он писали. Понял — толку НЕ БУДЕТ.
Их API годятся разве что для самых простых и примитивных программ, не более. Кто не верит, посмотрите сами.
Здравствуйте, IT, Вы писали:
IT>Фиг с ним с квазицитированием, но как они собираются без ПМ код анализировать?
Я, например, написал DSL для структурного поиска по коду с помощью Roslyn. Синтаксис — на основе object initializers.
(вообще-то я очень за ПМ, просто его в C# нет)
Здравствуйте, nikov, Вы писали:
N>Я, например, написал DSL для структурного поиска по коду с помощью Roslyn. Синтаксис — на основе object initializers.
К сожалению, любая эмуляция ПМ подручными средствами обычно даёт результат ниже среднего. Можно, например, выиграть в декларативности, но проиграть в производительности или сопроваждаемости такого кода.
N>(вообще-то я очень за ПМ, просто его в C# нет)
Это ваша недоработочка. Надо почаще и почувствительнее постукивать по темечку соответствующим товарищам.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Ну, так может пора дожать Хейльсберга, раз ты к нему теперь на чай можешь заходить. Очевидно, что он последний из магикан кто противится ПМ.
Никто ничему не противится. Всё определяется приоритетностью фич (не только фич языка, но и IDE, библиотек, API компилятора и т.д.) и наличием ресурсов (на дизайн, спецификацию, разработку, тестирование, документацию, поддержание обратной совместимости, поддержку в IDE/отладчике, возможный багфиксинг с выкатыванием сервис-паков, юридическую проверку возможных нарушений патентов и т.д.)
Здравствуйте, nikov, Вы писали:
N>Какой именно метод хотелось бы видеть открытым?
Сейчас уже из памяти все ушло. Если вы действительно можете пойти на большую отрытость АПИ, то могу глянуть еще раз и высказать детальные соображения.
Мне в первую очередь Рослин был интересен как бэкэнд.
Первое на что я нарвался — базовый классы часто были интернал, а сборки шарпа и ВБ тупо были связаны с ними атрибутом InternalsVisibleToAttribute. Вот это нужно вообще устранить, иначе даже странно говорить о поддержке других языков.
Хотелось бы иметь возможность спокойно получать любую метаинформацию из сборок и использовать для генерации однозначного кода. Ну, например, при генерации вызова метода нужно иметь возможность не полагаться на систему типизации шарпа, а иметь возможность указать конкретный вызываемый метод. Оптимально прямо ссылку на функцию в типизированном виде. В крайнем случае иметь возможность указать явно сигнатуру. Ну, и тоже самое для всех неоднозначных символов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Никто ничему не противится. Всё определяется приоритетностью фич (не только фич языка, но и IDE, библиотек, API компилятора и т.д.) и наличием ресурсов (на дизайн, спецификацию, разработку, тестирование, документацию, поддержание обратной совместимости, поддержку в IDE/отладчике, возможный багфиксинг с выкатыванием сервис-паков, юридическую проверку возможных нарушений патентов и т.д.)
Эдак можно обосновать что угодно. Тут нужна политическая воля (с)
Дизайн можно взять из того же немерла. Язык ведь не потентованный. Никто возражать не будет.
Тут важно понимать только одно. Вся эта филсофия про конструкторы что лежит под ПМ — это булшит. Реально паттерн описывает объект. А остальное — это уже ваши стандартные проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, nikov, Вы писали:
N>>Какой именно метод хотелось бы видеть открытым?
VD>Сейчас уже из памяти все ушло. Если вы действительно можете пойти на большую отрытость АПИ, то могу глянуть еще раз и высказать детальные соображения.
Тут вот какие соображения действуют. Если мы делаем API public, то мы этим заявляем, что мы его контракт полностью продумали и собираемся его поддерживать неограниченное время. А мы пока ещё сами многое пробуем, обкатываем, что-то меняем. Кроме того, public метод требует тщательного тестирования во всех возможных сценариях, а не только в тех, которые понадобились нам самим.
VD>Мне в первую очередь Рослин был интересен как бэкэнд. VD>Первое на что я нарвался — базовый классы часто были интернал, а сборки шарпа и ВБ тупо были связаны с ними атрибутом InternalsVisibleToAttribute. Вот это нужно вообще устранить, иначе даже странно говорить о поддержке других языков.
В первом релизе не стоит рассчитывать на возможность использования Roslyn как бэкэнда и на поддержку других языков, кроме C# и VB, а также на возможность вмешиваться в процесс компиляции после байндинга символов и типизации. Наша задача в первую очередь — предоставить read/write доступ к синтаксическому дереву, и readonly доступ к информации о типах и controlflow/dataflow (т.е. то что нужно для анализа кода и рефакторингов). Если не хватает public API из этой области, то мы постараемся это исправить. Но весь бэкэнд пока в internal режиме.
Здравствуйте, nikov, Вы писали:
N>В первом релизе не стоит рассчитывать на возможность использования Roslyn как бэкэнда и на поддержку других языков, кроме C# и VB, а также на возможность вмешиваться в процесс компиляции после байндинга символов и типизации. Наша задача в первую очередь — предоставить read/write доступ к синтаксическому дереву, и readonly доступ к информации о типах и controlflow/dataflow (т.е. то что нужно для анализа кода и рефакторингов). Если не хватает public API из этой области, то мы постараемся это исправить. Но весь бэкэнд пока в internal режиме.
Собственно именно это я и понял глядя на ваш код (да простят меня копирайты ).
Что касается "хватит", я уже сказал. Сделайте возможность ясно задать перегруженные символы. Пусть в нетипизированной форме, но четко.
Потом для маломалського метапрограммирования нужно сделать в компиляторе события на которые можно вмешаться процесс. Внешние приблуды приведут к зоопарку кривых решений.
ЗЫ
А вообще, дав возможность использовать шарп как бэкэнд (с чтением метаданным и генерацией сборок) вы бы резко упростили создание языков для .Net. SRE — это дырявое корыто. Ему давно пора на свалку.
В общем, если не в этой версии, то в следующих подумайте над созданием единого АПИ в замен SRE. Чем выше уровень будет у этого АПИ тем лучше.
ЗЫЫ
Ну, и подумайте, может проспонсируете работы над N2.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N> Если мы делаем API public, то мы этим заявляем, что мы его контракт полностью продумали...
Слишком самонадеянно. Вариантов использования roslyn может оказаться больше, чем может переварить сто Перельманов, тем более, что даже для самой MS подобная область — неизведанный край. Поэтому надо сначала дать людям всё, посмотреть на отклики (благо, никто на этих рослинах не будет писать фирмваре для космоса), а потом может даже "переписать всё с нуля", но теперь уже точно базируясь на реальных фактах использования.
"Продуманные" тырфейсы мелкософта для доступа к СУБД мне до сих пор доставляют море удовольствия.
Здравствуйте, nikov, Вы писали:
N>Тут вот какие соображения действуют. Если мы делаем API public, то мы этим заявляем, что мы его контракт полностью продумали и собираемся его поддерживать неограниченное время. А мы пока ещё сами многое пробуем, обкатываем, что-то меняем.
А что нельзя написать большими красными буквами, что данное API не стабильно и будет меняться?
Выставляется только для того чтобы получить фидбек.
И после получения фидбека будут ломающие изменения.
И если кто-то этот код использует, то он должен быть готов после очередного релиза изменить свой код.
Даже на таких условиях многие его будут использовать. Ибо SRE это ужОс-ужОс-ужОс-ужОс-ужОс-ужОс.
N>Кроме того, public метод требует тщательного тестирования во всех возможных сценариях, а не только в тех, которые понадобились нам самим.
Вот за вас и протестируют. Причем в таких положениях, что даже ты не придумаешь.
Здравствуйте, hardcase, Вы писали:
WH>>А что нельзя написать большими красными буквами, что данное API не стабильно и будет меняться?
H>Более того, у них такая практика есть. Например сжималка скриптов и стилей из следующей версии ASP.NET таким образом выложена на публику.
Это разные команды .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Очередная технология для мазохистов?
Если нам не помогут, то мы тоже никого не пощадим.
