Здравствуйте, nikov, Вы писали:
N>Создание спецификации — это первичный и отдельный процесс
Это называется водопадная модель разработки. Сначала делаем спеку, потом реализуем, и менять спеку больше не смей.
Сколько раз набивали шишки, сколько умных книг написано, что водопадная модель приводит к дерьмовому софту и раздутым бюджетам — а забеги по граблям начинаются снова и снова.
Здравствуйте, kleng, Вы писали:
K>Здравствуйте, nikov, Вы писали:
N>>Создание спецификации — это первичный и отдельный процесс
K>Это называется водопадная модель разработки. Сначала делаем спеку, потом реализуем, и менять спеку больше не смей.
Спеку можно поменять. Но порог изменений для уже выпущенного продукта очень высокий из-за требований обратной совместимости, и изменения требуют согласия многих заинтересованных сторон за переделами команды компилятора, и за пределами Microsoft. И, как я уже сказал, разработчик не должен самовольно отклоняться от существующей спецификации только потому, что дизайн кажется ему неудачным.
Для новых фич в языке обычно выпускаются CTP и Beta версии до того, как окончательная версия спецификации зафиксирована, и у всех пользователей есть возможность отправить свой feedback, который будет учтён в процессе дизайна. Но ждать десять лет после релиза, и потом ругаться на неудачный дизайн и некомпетенцию разработчиков — это совершенно неконструктивно и бесполезно. Причём в данном случае такой дизайн не был случайностью, явным образом зафиксирован и в спецификации CLR, и в спецификации C#, и имел веские доводы в свою поддержку.
Например, кто-то может захотеть иметь строковый тип со встроенным spellchecker'ом (или хотя бы с проверкой, что указанная последовательность code units даёт валидную строку в формате UTF-16), но это выходит за рамки того, для чего предназначен тип string. Точно так же, енумы — это немногим более, чем именованные алиасы для целочисленных типов с дополнительным набором именованных констант, несмотря на то, что кому-то хочется большей функциональности.
Здравствуйте, Sinix, Вы писали:
S>...В общем, roslyn стал фактически неизбежен
Это как раз с сильным пафосом и под воздействием наркотиков прессрелизов.
А по факту где-то перде 2002 годом была сделана одна глобальная (архитектурная) ошибка. Было принято решение писать компилятор C#/VB и language service-ы для них на С++.
Причем у них там в руководстве такое в голове было намешано, что они просто не доверяли своим продуктам. Им потребовалось около 10 лет чтобы решиться на бутстрапинг и около 5 лет на реализацию.
S>Делать в это время параллельно с рослином очередной big thing — самоубийство в чистом виде.
Строковая интерполяция — это не "big thing". Это вполне себе мелкая фишка. За пару месяцев одним человеком поднимается без проблем. Было бы кому спроектировать.
S>Вот и получается, что в один релиз с рослином укладывается только мелочёвка с синтаксическим сахаром
Связи с этрепрайзом не понял, но строковая интеполяция — это и есть мелкий синтаксический скхар. Уж поверь тому, кто это сам писал.
S>Ну а больше никаких принципиальных преимуществ у string interpolation нет.
Дык у МС никакой подержки нет. Честная строковая интерполяция куда лучше чем просто IDE-шная поддержка. Так что смысл в этом есть. Я все время плююсь когда на Шарпе приходится со строками работать.
В прочем, работать на Шарпе после Немерла или F# по любому не просто. Не проходит ощущение что ходишь с костылями.
S>Если они отпадают, то отпадают и ~70% сценариев использования. Подобное форматирование строк нужно разве что для лога, да и то не всегда. Для вывода пользователю нужна текущая культура + обычно форматирование берёт на себя биндинг в UI-фреймворке. Если запретить вызов методов, то придётся объявлять доп переменные вместо "Score: {GetScore()}" — ещё один минус, если сравнивать с string.Format().
Это ты из из своего опыта вывел? На моей практике $-строки используются довольно часто. Почти все ToString с его помощью реализуются. А одних их 100500 в проекте.
B>>Т.е. мы вводим фичу только для самых употребимых случаев: есть строка, в неё нужно вставить значение. S>А дальше все её используют и развивать фичу нельзя, т.к. запорется совместимость.
Если объявить фичу экспериментальной, никаких проблем не будет.
B>>Наконец, был озвучен не самый плохой вариант с "ёлочками": « и » (и тогда отпадает конфуз с verbatim: @«») S>Не вопрос, осталось оснастить каждую клавиатуру этими ёлочками и заодно убедить кое-какие системы CI что исходники c# в ASCII — это таки XIX векъ и нѣплохо бъ обновiться.
Это не аргумент. В студии кнопки биндятся на раз. Плюс копипаст никто не отменял. Да и быстро появится поддержка IDE. Вопрос только в том, что интерполяция в разных типах строк нужна. А для выделения сплайсов "ёлочки" просто излишни. Подхода Разора тут уместнее.
B>>Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать. B>>На данный момент никаких проблем не будет, если тупо ввести $ в существующие строки — хочешь — включай фичу, не хочешь (для легаси кода) — не включай. S>Всемогущество немерла из разряда неуловимого джо.
Ты хоть пробовал на нем писать? Или как про строковую интерполяцию вещаешь заочно с умным видом?
S>Можно переписывать и добавлять что угодно — язык экспериментальный, такие вещи в порядке вещей.
Может напомнишь сколько раз строковая интерполяция в Немерле изменялась? И вообще, сколько в Немерле было ломающих изменений?
S>С мейнстримом, увы, так не выйдет, слишком много граблей — от позабытой галочки, ушедшей в продакшн до геморроя с поддержкой исходников, работающих только под разными версиями компилятора.
Ага. Главной лицо серьезное делать, когда говоришь о том с чем не знаком. И умных слов типа "это же мэйнстрим". Тогда все поверят, что ты прав. Аргументы — это последнее дело.
На практике же проблемы совместимости здесь надуманы. Дизайн для фичи важен, но он уже сто раз сделан. Остается только остановиться на конкретном решении и реализовать его.
Немерл же в сто раз лучше шарпа хотя бы тем, что подобные решения у него можно поместить в библиотеку и спокойно менять. Сам язык от этого не портится. Не нужна тебе интерполяция строк — не используй соответствующий макрос. Нужна другая реализация — подключи ссылку к проекту и используй ее.
S>Угу, т.е. для вывода в html, для подстановки параметров в sql-запросы и для биндинга фича не годится, ещё минус 10-20% от сценариев использования.
Всемогуторы вообще не нужны. Для работы с XML/HTML нужно отдельное решение которое работает с тегами и знает формат. В том же немерле это отдельный набор макросов. Очень простенький и основанный на парсере ХМЛ-я. Что касается sql-запросов, то для этого есть LINQ. Он уже интегрирован в язык и является отдельным DSL-ем. Не фига его пытаться подменить строковой интерполяцией.
S>>>* Нужна ли функция обратного парсинга строки? B>>Не понимаю терминологии. О чём речь? S>
Это какая-то нематериализуемая фантазия. Парсинг несколько более сложная дисциплина. Все что можно сделать — это аналог scanf-а. Но он давно показал свою ненужность.
S>Угу, т.е. форматирование строк ресурсов и динамический sql в orm-провайдерах тоже идут лесом, т.к. не нужны(tm).
Именно. На то есть линк. Если захочется можешь сформатировать строку той же интерполяцией. Никто тебе не мешает.
S>Получается, делать interpolated string особого смысла нет.
Ну, да. Все просят потому что глупые.
S>Можно хоть один пригодный для продакшна пример?
Здравствуйте, nikov, Вы писали:
N>Спеку можно поменять. Но порог изменений для уже выпущенного продукта очень высокий из-за требований обратной совместимости
Doublespeak 80 уровня.
В нормальных условиях, сначала создается и обкатывается прототип, и уже потом по нему пишется спека и подается на стандартизацию.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, btn1, Вы писали: B>>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8? _ВСЕ_, от домохозяйки до программиста, знают — вышло полное гуано с абсолютно непотребным интерфейсом. Какие продажи ждут студию?
QL>Сколько желчи
Но по сути он прав. Если новая студия не будет работать под 7-кой — это будети форменное хамство. Почему человек дожен менять ОС ради смены компилятора?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, QrystaL, Вы писали:
QL>Пользуюсь с первых дней, после апдейта 8.1.1 стало практически неотличимо от 7.
Пользуясь дома так как в 8.1 все дрова для моей новой машины, но итерфейс поганый. У 7-ки был лучше. Метро-приложения вообще глупая идея на десктопе. Нормальнй скайп днем с огнем пришлось выискивать. Еле нашел. То что пропал способ открыть папку приложения в стартовом меню и посмотреть какие файлы в него входят — это вообще ужасно неудобно. Форменная деградация.
С другой стороны железо знает новое лучше. Работает шустро. В общем, системная часть в порядке. Индерфейс полное дерьмо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
B>>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access). G>>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?
VD>Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".
Ну вот по такой стратегии делали async\await, с разницей в том, что это был отдельный патч. И что? Массово его использовали и был хороший фидбек?
И это при том, что семантика async\await довольно простая с точки зрения потребителя.
Если экспериментальную фичу начнут массово использовать, но просто удалить в будущих версиях её не получится, поломается куча программ, а цель как раз этого избежать.
Если экспериментальную фичу не будут массово использовать, то заче все телодвижения.
Тем более есть два фактора, которые усугубляют ситуацию для интерполяции строк:
1) Интерполяция строк не настолько ценна
2) С использованием Roslyn потенциально можно реализовать эту фичу как захочется каждому разработчику самостоятельно (или скачать готовую либу из интернета).
В результате ситуация как сейчас вполне закономерна.
G>>С VM проще, ничего не мешает иметь несколько VM внутри процесса side-by-side и даже делать прозрачный маршалинг между ними. При этом CLR4 совместим с CLR2, то есть может в свою ВМ грузить сборки под старый фреймворк, так что и на этом уровне совместимость очень тщательно поддерживается. Хотя это и не так важно.
VD>Вообще-то косяков выше крыши. Фрейморки 4.0, 4.5 и 4.5.1 не совсем совместимы. Есть куча веселых проблем. Например, программа скомпилированная через Reflection.Emit на 4.5.1 фреймворке может не запуститься под 4.0, так как типы будут прибиндены так как они лежат в 4.5.1 сборках. VD>Было большой ошибкой делать 4.5.* фреймворки обновлениями для 4.0. Так что с совместимостью у донете все не очень хорошо. VD>Про приседания с версиями сборок я вообще молчу.
А никто не говорит то N+1 версия должна быть совместима с N. Важно чтобы N была совместима с N+1.
G>>Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6 (2006 год), а некоторые до сих пор используют Java 1.4. При этом с совместимостью у Java не сильно хуже, чем у C#. VD>Я знаю не мало людей которые не могли перейти с одной версии фреймворка на другую. Это не аргумент. В Яве все примерно тоже самое. Кто по шустрее переходит. Кто по осторожнее тормозит с переходом.
Я тоже знаю, но это чисто политическое решение, а не техническое. Например в одном банке очень долго не хотели ставить .NET 4 на клиентские машины и софт, который пилили подрядчики, вынужден был работать на .NET 3.5 чуть ли не до начала 2014 года. Хотя раскатать .NET по всей компании с помощью политики займет 20 минут работы и неделю подождать когда все компы перезагрузятся.
Здравствуйте, nikov, Вы писали:
N>А когда эти инициализаторы должны выполняться — до тела конструктора или после? до инициализаторов в базовом классе или после? до конструктора базового класса или после?
Просто скопировать инициализатор в бэк-поле (чтобы работало по его логике).
N>Нужно ли выполнять инициализатор свойства в базовом классе, если оно virtual и имеет override в производном классе с другим инициализатором?
Нужно, так есть base.-доступ. Смысла в виртуальных (не абстрактных) авто-свойствах не много. Но переопределяться они ведь и в нескольких потомках могут.
Опять же копируем инициализатор в свое поле (оно же дублируется при оверрайде, если в базовом типе тоже автосвойство было).
N>Компилятор должен быть спроектирован так, чтобы автоматически правильно ответить на все эти вопросы после правки EBNF, правда?
Правда. Только при наличии хорошего АПИ можно за денек реализовать фичу и протестировать ее на практике. А при наличии макро-системы еще и выдать ее пользователям в виде экспериментальной библиотеки.
Проектирование конечно нужно и важно. Но не по 5 же лет на мелкую фичу тратить. Если у вас с этим проблемы — отдавайте на аутсорс. Я с радостью возьму себе такую подработку.
Плюс, не смотря на не малое время затрачиваемое в МС на проектирование все равно остается много ошибок в проектировании. Пресловутые делегаты отличный тому пример. Правильным выходом было бы исправлять косяки. Те же делегаты можно было бы переделать на базе функционального типа. За одно type def бы реализовали.
N>И заодно сам сочинить сообщения об ошибках для всех некорректных случаев? Или достаточно сказать "ваша программа не соответствует EBNF"?
Почините в процессе тестирования. Это не бином Ньютона. Тут скорее вопрос в том чему нужно отдавать приоритеты. В МС они частенько отдаются пиару/промывки мозга. Причем сначала всем промывают мозг на тему того почему фича/подход не нужна, а потом почему она необходима.
Если же вложить время и деньги в инфраструктуру, то дальнейшее развитие фич будет идти куда проще, быстрее и дешевле.
А мокросы нужны языку хотя бы для тестирования новых фич и внутренней разработки.
В прочем, это даже хорошо, что в МС не делают все как надо с первого раза. Это дает жить и другим игрокам на рынке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Прототипы писали, и там далеко не 20 строк.
Не 20. Но и не года несустветные. За месяц запилить можно без проблем.
N>Начнём с того, что строковые литералы перестают быть монолитными токенами, и должны теперь содержать синтаксические узлы, которые могут представлять имя переменной (константы, поля, свойства...). Эти синтаксические узлы могут иметь собственные предупреждения/ошибки, которые не относятся к строке в целом (использование переменной до присваивания, доступ к экземплярному члену из статического контекста, использование Obsolete члена...). Также другие фичи, как, например, Find All References, Rename refactoring, Extract Method refactoring должны знать о наличии этого узла, и правильно его обрабатывать.
Какие-то отмазки. Ну, да содержат, должны и т.п. Что в этом страшного то? Берем строку, парсим. Получаем отрезки строк и отрезки кода. Трансформируем выражение (генерируем код) и получаем окончательный вариант который и подвергаем типизации. все описанное выше получается в автомате.
N>Ввиду того, что такие строки могут перестать быть constant expressions (ещё вопрос: может быть, они должны оставаться constant expresions, если все interpolated expressions — константы?), надо исправлять код, работающий с constant expressions, и с другими категориями "почти константных" выражений, как, например, аргументы атрибутов.
Не надо. Просто надо рассматривать строковую интерполяцию как обычное не константное выражение.
N>Каким образом значение interpolated expression должно преобразовываться в строку? С помощью вызова метода .ToString()? А если там null, то должно быть исключение, или пустая строка, или специальная строка "<null>"?
Ну, у тебя то доступ к немерлу есть. Погляди как у нас сделано. Да и спросить на форуме можно, что народ хочет.
Нулы, конечно же, нужно превращать в пустые строки. Исключения при работе со строками никому не нужны.
Если кому-то понадобится специальная обработка, он преобразование в функцию завернет.
N> А если объект скрывает виртуальный метод .ToString(), унаследованный от object, с помощью другого метода или свойства? Должна ли это быть ошибка, или мы должны попытаться вызвать этот метод или свойство (надеясь, что оно возвращает подходящий тип), или мы должны всё-таки вызвать скрытый базовый метод? А если intepolated expression имеет тип dynamic, должен ли это быть динамический вызов метода .ToString()?
Это не суть важно. Если кому-то не понравится ваше поведение он всегда его сможет подменить переводя объект в строку самостоятельно. Надо выбрать одну стратегию и придерживаться ее везде и всегда. Или тупо использовать паттерн .ToString() (перекрыт не перекрыт — не важно) или всегда кастить к обжекту и звать виртуальный. Главное чтобы не было и то, и то. Я оборачивал сплайсы в вызовы System.Convert.ToString(). Это упрощало реализацию и давало однообразную логику.
N>А затем, должен ли это быть динамический вызов оператора + в выражении "..." + d.ToString() + "..."? А окончательный тип выражения должен быть тоже dynamic, или мы должны динамически вызвать (возможно, user-defined) оператор приведения к string?
Все что внутри сплайса должно вычисляться по обычной логике выражений. Далее, к результату, должен применяться единый подход преобразования. Люди должны иметь понятный алгоритм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kleng, Вы писали:
K>Здравствуйте, nikov, Вы писали:
N>>Спеку можно поменять. Но порог изменений для уже выпущенного продукта очень высокий из-за требований обратной совместимости
K>В нормальных условиях, сначала создается и обкатывается прототип, и уже потом по нему пишется спека и подается на стандартизацию.
Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?
Здравствуйте, nikov, Вы писали:
N>Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?
Только не надо юлить. Реализация кривая, и глупо с этим спорить.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, nikov, Вы писали:
N>>Прототипы писали, и там далеко не 20 строк.
VD>Не 20. Но и не года несустветная. За месяц за пилить можно без проблем.
Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке? Между прочим, Roslyn — это open source библиотека. Ты можешь реализовывать фичи и посылать пул реквесты.
VD>Какие-то отмазки. Ну, да содержут, доллжны и т.п. Что в этом страшнокго то? Берем строку, парсим. Получаем отрезки строк и отрежки кода. Трансформируем выражение (генерируем код) и получаем окончательный вариант который и подвергаем типизации. все описанное выше получается в автомате.
В Nemerle работает Extract Method рефакторинг с интерполированными строками? А с частью выражения после $ в интерполированной строке?
VD>Не надо. Просто не надо рассматривать строковую интерполяцию как обычное не константное выражение. VD>Нулы, конечно же, нужно превращать в пустые строки. Исключения при работе со строками никому не нужны. VD>Если кому-то понадобится специальная обработка, он преобразование в функцию завернет. VD>Это не суть важно. Если кому-то не понравится ваше поведение он всегда его сможет подменить переводя объект в строку самостоятельно. Надо выбрать одну стратегию и придерживаться ее везде и всегда. Или тупо использовать паттерн .ToString() (перекрыт не перекрыт — не важно) или всегда кастить к обжекту и звать виртуальный.
Видишь, все эти пункты требуют принятия каких-то решений. И это не может быть сделано одним человеком, так как человеку свойственно ошибаться. И мы не можем потом поломать код у тысяч разработчиков, потому что какое-то решение было неудачным и нуждается в исправлении. А неудачные (или даже в чём-то спорные решения) приведут к тому, что люди потом будут ругать Microsoft десятилетиями (см. этот тред выше).
Здравствуйте, kleng, Вы писали:
K>Здравствуйте, nikov, Вы писали:
N>>Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?
K>Реализация кривая, и глупо с этим спорить.
Это не так. Реализация абсолютно правильная, и в точности соответствует международно принятой спецификации.
Дизайн перечислений, как он закреплён в спецификации, изначально являлся неоднозначным вопросом, и имел аргументы как за, так и против. Решение, которое было принято, выглядит вполне уместным: и с точки зрения перформанса, и с точки зрения возможности работать с битовыми флагами, и с точки зрения простого интеропа с существующими COM-интерфейсами. Решение выглядит, как не подлежащее изменениям, по причине необходимости поддержания обратной совместимости (даже если бы баланс аргументов за и против изменился с тех пор). Существуют альтернативные механизмы, позволяющие реализовать значения, принимающие только указанное множество объявленных значений (например, абстрактный класс с вложенными наследниками-синглетонами). Язык не вынуждает пользователя использовать енумы, если они не подходят для его задач.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
B>>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access). G>>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?
VD>Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".
Здравствуйте, VladD2, Вы писали:
VD>То что пропал способ открыть папку приложения в стартовом меню и посмотреть какие файлы в него входят — это вообще ужасно неудобно. Форменная деградация.
Если речь идет об обычных приложениях (не метро), то можно открыть папку. Правый клик по приложению > Открыть расположение файла
Здравствуйте, nikov, Вы писали:
N>Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке?
Не думаю. Но прошло уже 5 лет как пилится Рослин (я не ошибаюсь?). Можно было такую мелочь и реализовать. Фича мелкая, но очень удобная. Плюс вау-эффект. Учитывая, что ты сам говоришь, что работы велись, не ясно что могло привести к решению их остановить.
N>Между прочим, Roslyn — это open source библиотека. Ты можешь реализовывать фичи и посылать пул реквесты.
Ну, Nitra тоже теперь опен-сорс. Так что ты тоже можешь нам помочь.
Сам понимаешь, у нас тоже объем работ большой, а команда сильно меньше вашей.
В прочем, я может и потратил бы время если бы был уверен, что время не будет потрачено зря. Но судя по тому что вы и свою реализацию выкинули вряд ли на это можно надеяться.
N>В Nemerle работает Extract Method рефакторинг с интерполированными строками? А с частью выражения после $ в интерполированной строке?
В немерле вообще нет Extract Method. Не было кому запилить. Но тот же рефакторинг переименования работает и внутри сплайсов. Extract Method просто запретить работать в условиях когда выделение пересекает границы сплайсов. Допускать рефакторинг только внутри одного сплайса или вне $-строки.
N>Видишь, все эти пункты требуют принятия каких-то решений.
В любой работе нужно постоянно принимать решения. В дизайне — это основная задача. Кто же спорит то. Но за 5 лет то уж можно было потратить некоторое время на дизайн. Тем более, что вы не с нуля фичу делаете, а повторяете имеющуюся не в одном языке. Если есть сомениния — обращайтесь к нам (немерлистам). Мы с радостью расскажем о проблемах и путях и возможного обхода.
N>И это не может быть сделано одним человеком, так как человеку свойственно ошибаться. И мы не можем потом поломать код у тысяч разработчиков, потому что какое-то решение было неудачным и нуждается в исправлении. А неудачные (или даже в чём-то спорные решения) приведут к тому, что люди потом будут ругать Microsoft десятилетиями (см. этот тред выше).
Парень тут дело сказал. Да и ты правильную мысль на счет пул-реквеста высказал. Если это теперь опен-сорс, то можно сделать отдельный клон и там запилить фичу. Потом выдать народу пробную версию на тестирование и устроить опрос. Забросить на РСДН и Стек оверфлоу. Будет вам фитбек в лучшем виде.
Что до решений, то решения всегда принимает один человек. Коллективное принятие решений не бывает. В коллективе можно обсуждать принимаемые решения и анализировать проблемы. Но решение все равно кому-то принимать. По сему в таких вещах лучше кому-то сделать прототип, а потом уже его обсуждать и корректировать.
Уверяю тебя, что хорошо сделанная строковая интерполяция (ака бакс-строки) — это очень удобная фича за которую народ будет примного благодарен. Главное чтобы при ее реализации была поддержка не просто вставок отдельных объектов, но и поддержка вставок коллекций с разделением элементов и возможностью подсунуть свою функцию преобразования элемента в строку. Посмотри наши бакс-строки. Там это все сделано. Еще полезно было бы сделать необязательное формарирование (как в стринг-формате). У нас этого нет, но иногда хочется.
В общем, если нужно могу помочь идеями. На реализацию вряд ли время смогу выкраить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как я понял даже при включении эксперементальных фич их понимает только компилятор. Почему их не понимает лэнгвидж-сервис? Как я понял весь смысл Рослина в том, что он переиспользует и для компилятора, и для лэнгвидж-сервиса один и тот же код. Я что-то не так понял?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Это не так. Реализация абсолютно правильная, и в точности соответствует международно принятой спецификации.
Я бы сказал, что спецификация довольно спорная. Оставляет возможность для нелепых ошибок. Единственный разумный аргумент за нее — производительность. Рантайм-проверки энумов были бы дороким удовольствием.
Сейчас уже менять спки поздно. Слишком много кода использует особенности энумов.
Но можно ведь сделать алгеброические типы которые в том числе закроют вопрос строгих энумов. Это, конечно, не мелкая фича, но продвинутый народ ждет ее от вас уже очень давно.
Сейчас кода у вас есть Рослин было бы разумно начать работу над алгеброическими типами и паттерн-матчингом.
Еще одна интересная тема — это объеденение и пересечение типов. Ее можно отлично совместить с алгеброическими типами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
