Здравствуйте, hi_octane, Вы писали:
_>То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями. Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался?
На всякий случай — это не "забыли" или "не догадались" сделать. Возможная расширяемость, как на стороне потребителя (кодогенерация для await), так и на стороне производителя (кодогенерация для async методов) активно обсуждалась и прототипировалась. Рассматривались, в том числе, возможность использования await внутри методов-итераторов и добавление интерфейсов IAsyncEnumerable/Enumerator с асинхронным методом MoveNext. В конечном счёте, после оценок стоимость/полезность, было решено остановиться на расширяемости только на стороне потребителя (кастомный awaiter). Это то, что могло быть сделано в намеченные сроки с достаточным качеством, и покрыть значительную часть спроса пользователей. Возможные дальнейшие улучшения были отложены на следующие версии. Например, await в catch/finally блоках был позже реализован в Roslyn (что потребовало довольно хитрой кодогенерации).
Здравствуйте, btn1, Вы писали:
B>Я не корю их за то, что такую тривиальщину не сделали до этого (хотя и могли). Я не понимаю, почему сейчас это отнимает столько времени!? Ты ж прогер, просто сядь за листок и набросай псевдокод — да там от силы 20 строк получится!
Прототипы писали, и там далеко не 20 строк. Начнём с того, что строковые литералы перестают быть монолитными токенами, и должны теперь содержать синтаксические узлы, которые могут представлять имя переменной (константы, поля, свойства...). Эти синтаксические узлы могут иметь собственные предупреждения/ошибки, которые не относятся к строке в целом (использование переменной до присваивания, доступ к экземплярному члену из статического контекста, использование Obsolete члена...). Также другие фичи, как, например, Find All References, Rename refactoring, Extract Method refactoring должны знать о наличии этого узла, и правильно его обрабатывать.
Ввиду того, что такие строки могут перестать быть constant expressions (ещё вопрос: может быть, они должны оставаться constant expresions, если все interpolated expressions — константы?), надо исправлять код, работающий с constant expressions, и с другими категориями "почти константных" выражений, как, например, аргументы атрибутов.
Каким образом значение interpolated expression должно преобразовываться в строку? С помощью вызова метода .ToString()? А если там null, то должно быть исключение, или пустая строка, или специальная строка "<null>"? А если объект скрывает виртуальный метод .ToString(), унаследованный от object, с помощью другого метода или свойства? Должна ли это быть ошибка, или мы должны попытаться вызвать этот метод или свойство (надеясь, что оно возвращает подходящий тип), или мы должны всё-таки вызвать скрытый базовый метод? А если intepolated expression имеет тип dynamic, должен ли это быть динамический вызов метода .ToString()? А затем, должен ли это быть динамический вызов оператора + в выражении "..." + d.ToString() + "..."? А окончательный тип выражения должен быть тоже dynamic, или мы должны динамически вызвать (возможно, user-defined) оператор приведения к string?
Если всё это встречается внутри expression tree, должны ли мы создать новый вид узлов для таких строк (и предоставить всем LINQ провайдерам самостоятельно разбираться с ними)? Или же мы должны создавать дерево, в котором эти строки представлены уже в раскрытом виде? Или просто запретить их в этом контексте (и добавить новое сообщение об ошибке)?
Нужно ли проправлять CodeDOM API? И т.д. (А то иначе ведь в Microsoft такие идиоты, в одном месте фичу с горем пополам приделали, а про остальные очевидные места, с которыми она связана, как всегда забыли...)
Здравствуйте, btn1, Вы писали:
B>Я не понимаю, как можно "проигрывать" там, где ты тупо делаешь язык лучше!
Очень просто. Можно случайно выбрать неудачный синтаксис для полезной (но малополезной) фичи так, что это заблокирует или сильно затруднит добавление очень полезной фичи в наиболее удобном и естественном синтаксическом виде в следующей версии.
Здравствуйте, btn1, Вы писали:
B>Прям вас с Липпертом послушать — мелкософт-рабы с утра до ночи трудятся на благо студии и фичи у них как из мясорубки — лезут и лезут, делая жизнь прекраснее! Фиг-два, там сидят отъетые тюлени и тоже не особо спешат работать — ведь отговорки уже придуманы, чё париться?
Смею тебя заверить — бездельников в команде компилятора нет.
B>Нет времени? Ах вы, ***, бедненькие, в поту и крови пашете под палящим солнцем, жену-детей не видели пол-года! Так штоле? Нет. Сидят, крутят свои ж**ы в креслах, пьют кофе, рассуждают о выходных — обычная офисная работа! Нет рук? Я тя умоляю, НАЙМИ ЕЩЁ ЛЮДЕЙ, но только не индусов! Пройдёт пол-года и каждый член команды будет с лёгкостью факира выкатывать фичи.
"Некоторые менеджеры думают, что если нанять девять женщин, то можно родить ребёнка за один месяц." (c)
И, между прочим, найти и нанять разработчика компилятора высокого уровня — достаточно сложная проблема, которая уж точно не решается проверкой страны происхождения.
Здравствуйте, Sinix, Вы писали:
S>сверхзнающих разработчиков нет
Да ладно, это вовсе не рокет сайенс. Я видел кое-какой их код в VS SDK, это лютый говнокодище, за который даже студенту должно быть стыдно.
Надо просто нанимать знающих людей, а не гномосортировщиков.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, btn1, Вы писали:
B>>проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")
AVK>Надо внимательнее читать сопроводительный текст. Выставлять не 6.0, а Experimental.
1. Читал, выставлял — бестолку. В какой-то момент ворнинги пропали, но перезапущенная студия снова разругалась.
2. Какого чёрта в свойствах проекта есть C# 6.0, но при этом нету Experimental? Какая между ними разница? И наконец, если уж выкатили CTP (априори "нерабочая" среда), можно уж было поднапрячь зад и сразу создавать проекты с необходимым значением языка — CTP для того и предназначен, чтобы тестировать НОВЫЕ ФИЧИ, которые по дебильному стечению обстоятельств недоступны искаропки.
Что делал я: создал проект, написал неработающие фичи, среда разругалась. Проект сохранил, выставил язык Experimental, открыл проект — вроде бы предупреждения исчезли, потом что-то отредактировал, компильнул — среда опять ушла в отказ и C# 6.0 перестала понимать. Затем выставил 6.0 через свойства проекта — тоже бестолку.
И опять возвращаемся к вопросу о жадности: сколько можно экономить на индусах и выкатывать откровенный отстой?
как указано в инструкции. Фичи не включены по умолчанию, потому что они экспериментальные, и могут быть убраны или существенно измениться к релизу C# 6.0.
Здравствуйте, kleng, Вы писали:
K>Да ладно, это вовсе не рокет сайенс. Я видел кое-какой их код в VS SDK, это лютый говнокодище, за который даже студенту должно быть стыдно.
Из "Я видел косяки в A" никак не следует "B и C — отстой", это ошибка в логике.
VS SDK и компиляторы — это два сильно разных проекта. Разная ценность, разная аудитория, разные риски. Подбор специалистов соответствующий.
Здравствуйте, btn1, Вы писали:
B>1. Читал, выставлял — бестолку. В какой-то момент ворнинги пропали, но перезапущенная студия снова разругалась.
Студия новые фичи не поддерживает, только компилятор. Я здесь уже несколько раз об этом писал.
B>2. Какого чёрта в свойствах проекта есть C# 6.0, но при этом нету Experimental?
Тебе нужно перевести слово experimental?
B>И наконец, если уж выкатили CTP (априори "нерабочая" среда), можно уж было поднапрячь зад и сразу создавать проекты с необходимым значением языка — CTP для того и предназначен
Нет, не только для этого. Основная цель этого CTP — понять насколько хорошо новые языковые пакеты обеспечивают совместимость, а вовсе не обкатка новых фич языка.
... << RSDN@Home 1.2.0 alpha 5 rev. 71 on Windows 8 6.2.9200.0>>
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, hi_octane, Вы писали:
F> Да не нужна культура программистам. Там где она реально нужна — они об это осведомлены. F> не нужна культура программистам.
K>Глядя на такие фокусы, мне с трудом верится в высокий профессиональный уровень разработчиков компилятора.
Ты читал спецификацию C#, спецификацию CLI? Они требуют, чтобы енумы работали именно так.
Есть метод, который позволяет явно проверить, что значение енума соответствует одному из именованных элементов.
Здравствуйте, Sinix, Вы писали:
S>Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:
Вопросы высосаны из пальца. Большая часть вопрос дизайнерского выбора. Как бы они не были решены все равно буде лучше чем никак.
S>* Как объявлять такие строки — с префиксом $"Hi, {Name}!" или через "Hi, \{Name\}!"?
Лучше как вразоре. @ (или другой символ) за которым идет выражение C#. В сложных случаях можно будет взять выражение в скобки:
var str = $"Привет, $GetName()!";
str -> Привет, Вася!
S>* Как экранировать скобки в первом случае: как в шарпе, или как в string.Format ("\{" vs "{{")?
Удвоением, чтобы во всех строках работало.
S>* Что насчёт verbatium strings, не будет ли перебором $@"Hi, {Name}!"
Нет. Не будет.
S>* Допустимы ли выражения внутри "{Name}", или только идентификаторы? Вызов методов?
Допустимы.
S>* Поддерживать ли этот формат в [DebuggerDisplay]? API для подобных атрибутов?
Никакой связи. Это всего лишь студийная апишка.
S>* Какая культура должна быть по умолчанию? Нужен ли способ явно указать культуру?
Есть культура ассоциированная с потоком. Ничего больше не нужно.
S>* Добавлять ли синтаксис форматирования от string.Format() ( $"{time:0.0##} second(s) left!")? Кидать ли ошибки при неверном синтаксисе?
Имеет смысл, хотя и без этого можно жить. Можно как раз использовать синтаксис ${...:формат} для таких целей.
S>* Нужна ли возможность заменить interpolator (штуку, которая будет раскрывать выражения в {})? Если да — какие сценарии надо учитывать — razor, sql-форматтеры, биндинг, ещё что-нибудь?
Это статическое решение. Все преобразования должны во время компиляции делаться.
Вот что реально нужно, так это синтаксис работы со списками и возможность заменять функцию преобразования элемента в строку.
S>* Нужна ли функция обратного парсинга строки?
Что за чушь?
S>* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic?
Фича статическая. dynamic просто не о чем. В expression tree уже преобразованный код будет.
S>* Как насчёт динамических строк, например, строк из ресурсных сборок?
Очевидно — никак. Это все же языковый литерал, а не динамическая строка. Для динамики остается string.Format и т.п.
S>ну и тд и тп.
Из пальца можно много разных вопросов высосать. А люди будут еще 10 лет палец сосать.
S>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай
Это все отмазки. Со времен рождения языка прошло 12 лет. Куча других языков аналогичную фичу заимело.
Правильным подходом было бы предложить макросы как в Nemerle и Scala (скоро появятся, пока в альфа-версии). Тогда люди смогли бы для себя сами нужные реализации сделать. Причем на альтернативной основе.
Но МС в свой дизайн подобную гибкость не закладывает. Даже в Рослине все гвоздями будет прибито (похоже).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, btn1, Вы писали:
B>Вопрос только, а зачем вообще нужен префикс??
Префиксы позволяют избежать пересечений с обычным текстом.
B>Что, старые строки нельзя "рассматривать по-новому"?
Ломать совместимость со старым кодом — это плохая идея. Префиксы же позволяют и синтаксически выделить конструкцию, и совместимость сохранить.
B>Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать.
Согласен, но как пользователь этого решения скажу, что Разоровский подход удобнее. Лучше считать, что за $ (или другим символом) идет корректное выражение. Будет это вызов метода, идентификатор (переменная) или скобки с выражением — не важно. В неоднозначных случаях скобки помогут. Но они будут нужны очень редко.
S>>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай
B>Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.
Это называется — verdesign. Когда люди начинают проектировать конкретную вещь, но все время получается вселенский всемогутер.
С другой стороны продумать все как следует и попробовать на людях тоже надо. Это не Немерл где строковая инерполяция не более чем библиотечный макрос. Тут язык изменяется навсегда. Если сделать криво обратной дороги уже не будет (без разрыва совместимости).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kleng, Вы писали:
N>>Ты читал спецификацию C#, спецификацию CLI? Они требуют, чтобы енумы работали именно так.
K>Ну если нелепость внесли в спецификацию, то это конечно уже не нелепость.
Спецификация не является описанием того, как разработчики компилятора сделали ту или иную фичу. Создание спецификации — это первичный и отдельный процесс, вовлекающий множество заинтересованных сторон, и проходящий через международные организации по стандартизации (ECMA, ISO). Есть способы повлиять на этот процесс, если ты считаешь, что дизайн является неудачным и требует изменений. Но от квалифицированного разработчика компилятора уж никак не ожидается, что он будет оценивать лепость или нелепость требований, закреплённых в спецификации, и отклоняться от них по своему усмотрению.
Здравствуйте, gandjustas, Вы писали:
B>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access). G>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?
Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".
G>С VM проще, ничего не мешает иметь несколько VM внутри процесса side-by-side и даже делать прозрачный маршалинг между ними. При этом CLR4 совместим с CLR2, то есть может в свою ВМ грузить сборки под старый фреймворк, так что и на этом уровне совместимость очень тщательно поддерживается. Хотя это и не так важно.
Вообще-то косяков выше крыши. Фрейморки 4.0, 4.5 и 4.5.1 не совсем совместимы. Есть куча веселых проблем. Например, программа скомпилированная через Reflection.Emit на 4.5.1 фреймворке может не запуститься под 4.0, так как типы будут прибиндены так как они лежат в 4.5.1 сборках.
Было большой ошибкой делать 4.5.* фреймворки обновлениями для 4.0. Так что с совместимостью у донете все не очень хорошо.
Про приседания с версиями сборок я вообще молчу.
Но, конечно же, это не оправдывает создание не совместимости на уровне языка.
G>Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6 (2006 год), а некоторые до сих пор используют Java 1.4. При этом с совместимостью у Java не сильно хуже, чем у C#.
Я знаю не мало людей которые не могли перейти с одной версии фреймворка на другую. Это не аргумент. В Яве все примерно тоже самое. Кто по шустрее переходит. Кто по осторожнее тормозит с переходом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
