Сначала маркетолог утверждает, что продажи провалились из-за отсутствия фонарика, а потом вдруг оказыватся, что освещать дорогу айфоном в России — дурная примета. Так я не понял: если бы в айфонах был фонарик, продажи бы выросли или нет? Логика отсутствует. Такого маркетолога нужно гнать в шею… (Не то чтобы у меня совсем нет чувства юмора, но сюжет не очень).
Я думаю, что лет через 5-10 после введения WiMax все забьют на сотовую связь и будут разговаривать по VoIP. Так что уровень электромагнитного фона упадёт до текущего, или даже уменьшится, т. к. уйдёт WiFi и ещё кучка подобных радио-технологий.
А ещё хотелось бы обратить внимание на то, что когда нажимаешь кнопку «Назад», страница всегда скроллится на начало. А по хорошему позиция должна запоминаться.
А я бы сделал драйвер для файловой системы, чтобы удалённые файлы ничем не отличались от локальных. Тогда проблема апдейтов со стороны сводится к проблеме апдейта одного файла из двух открытых редакторов на одном и том же компьютере. Так как эта проблема в существующих редакторах пока не решена, то на неё можно просто забить =)
Ничего сложного? Если бы ничего сложного в этом не было, тогда бы не существовало так много различных систем контроля версий. Как вы представляете полностью автоматизированный merging файлов? А если расширить данную концепцию до возможности редактирования документов любого типа, а не только txt, то задача merging-а получается вообще невыполнимой. Единственный вариант — использовать транзакции. А следствием этого будет неминуемые блокировки или создание копий редактируемых документов.
Лексический сахар:
1) Я бы хотел, чтобы в C# 4.0 ввели специальный тип строковых литералов для описания регулярных выражений а-ля JS. Было бы намного приятнее писать и понимать /«\d*»/ вместо «\»\\d*\«». Но тут, конечно, надо предусмотреть все нюансы лексического анализа подобных выражений.
2) Было бы круто использовать подстановку значений переменных в строковые литералы, используя EL JSP-style, то есть, что-то вроде такого: «x = ${x}».
Синтаксический сахар:
1) Константный switch. Кажется, идея заимствована из языка D, хотя не уверен.
Суть в том, что если перед switch стоит слово const, то внутри switch-a должны быть рассмотрены все случаи ветвления. Иначе происходит ошибка компиляции. Это удобно для отлова ситуаций, когда в некий enum добавляется новое значение, и необходимо проверить все места, на которые может повлиять это изменение.
2) Не пойму, накой чёрт я должен писать «using System.Linq;» в каждом файле, где использую Linq?
Ну и вообще:
1) Расширенные средства кодогенерации. В этой области в МС ещё конь не валялся;
2) Чтоб C# 4.0 был написан на C# 4.0 и с открытыми исходными кодами.
Много хотелок по поводу недостатков FCL.
Например, мечтаю, чтоб CodeDOM мог парсить файлы и строить синтаксические деревья. АФАИК, интерфейсы для этого есть, но все мои попытки приводили к исключениям.
И ещё было бы круто иметь мощный интегрированный в FCL фреймворк для написания собственных языков программирования. Чтобы не заморачиваться со сторонними средствами, у которых, как правило, поддержка оставляет желать лучшего.
Но это уже не C#.
P.S. Наверняка много чего забыл. Сразу всё сложно вспомнить.
А, понял. Ну да, можно было бы сделать что-нибудь такое (только название поменять, конечно =)
Но что мешает лично вам уже в .Net 3.0 добавить extension method WeCanView к классу DirectoryInfo?
Чего хотят программисты:
1) Опциональные параметры в функциях и методах — это как?
2) Сделать опциональным ключевое слово «var», все равно будем отталкиваться от названия переменной. — То есть разрешить пользователю писать просто «a = 5;», а компилятор всё сам поймёт?
Во-первых, это увеличит сложность синтаксического анализа, а значит и понизит внятность сообщений об ошибках. Но самое главное — будет сложно понять, вводим ли мы новую переменную, или используем старую. А если ошибиться в имени существующей переменной при присваивание, то замучаешься отлаживаться.
3) Вывести «var» за пределы функций/методов. Мне кажется, это невозможно. Вернее, возможно, но только для private-элементов. Да и не нужно это.
4) Проваливающийся switch. Это ужасно. =) Подобная констукция специально не используется в C#, так как подобное поведение нужно нечасто, зато ошибки из-за этого происходят постоянно. Самый правильный вариант в этом случае, я считаю, использовать оператор «goto xxx;» вместо «break;», где xxx — метка следующего кейса (в этом случае это не антипаттерн).
5) Использовать в switch не «константные варианты». — Вот это и правда полезно.
6) List<var> SomeList = new List<string>(); — Не вижу смысла.
7) [NotNull] атрибут для типов данных. — А как это реализовать? Автоматически вставлять проверку на null при каждом присваивании? Можно, но тут, как мне кажется, много нюансов…
8) Интегрировать частично возможности Spec# — какие? =)
9) Mixing как в Ruby — не знаком с Ruby, но mixin-ы — это круто =)
10) Мета-программирование на стадии компиляции. — Однозначно «Да»!
Что не хватает мне:
1) Не понял =)
2) PNG сжатие, оно есть но не работает. — это скорее вопрос к разработчикам GDI+
3) Убрать «прикол», когда нужно каждый раз сохранять JPG с качеством 75%, ибо если 100%, то эффекта нет, а размер файла растет. — не сталкивался, не знаю.
4) В WinForms (в WPF не пробовал) возможность работать объекту на форме (контролу) в другом потоке. — Прямой путь к deadlock-ам. Думаете, это случайно так сделали?
5) Это относится к Visual Studio, но напишу: Дизайнер WCF конфигурации. Дайте! Да! =)
Лексический сахар:
1) Я бы хотел, чтобы в C# 4.0 ввели специальный тип строковых литералов для описания регулярных выражений а-ля JS. Было бы намного приятнее писать и понимать /«\d*»/ вместо «\»\\d*\«». Но тут, конечно, надо предусмотреть все нюансы лексического анализа подобных выражений.
2) Было бы круто использовать подстановку значений переменных в строковые литералы, используя EL JSP-style, то есть, что-то вроде такого: «x = ${x}».
Синтаксический сахар:
1) Константный switch. Кажется, идея заимствована из языка D, хотя не уверен.
Суть в том, что если перед switch стоит слово const, то внутри switch-a должны быть рассмотрены все случаи ветвления. Иначе происходит ошибка компиляции. Это удобно для отлова ситуаций, когда в некий enum добавляется новое значение, и необходимо проверить все места, на которые может повлиять это изменение.
2) Не пойму, накой чёрт я должен писать «using System.Linq;» в каждом файле, где использую Linq?
Ну и вообще:
1) Расширенные средства кодогенерации. В этой области в МС ещё конь не валялся;
2) Чтоб C# 4.0 был написан на C# 4.0 и с открытыми исходными кодами.
Много хотелок по поводу недостатков FCL.
Например, мечтаю, чтоб CodeDOM мог парсить файлы и строить синтаксические деревья. АФАИК, интерфейсы для этого есть, но все мои попытки приводили к исключениям.
И ещё было бы круто иметь мощный интегрированный в FCL фреймворк для написания собственных языков программирования. Чтобы не заморачиваться со сторонними средствами, у которых, как правило, поддержка оставляет желать лучшего.
Но это уже не C#.
P.S. Наверняка много чего забыл. Сразу всё сложно вспомнить.
Но что мешает лично вам уже в .Net 3.0 добавить extension method WeCanView к классу DirectoryInfo?
1) Опциональные параметры в функциях и методах — это как?
2) Сделать опциональным ключевое слово «var», все равно будем отталкиваться от названия переменной. — То есть разрешить пользователю писать просто «a = 5;», а компилятор всё сам поймёт?
Во-первых, это увеличит сложность синтаксического анализа, а значит и понизит внятность сообщений об ошибках. Но самое главное — будет сложно понять, вводим ли мы новую переменную, или используем старую. А если ошибиться в имени существующей переменной при присваивание, то замучаешься отлаживаться.
3) Вывести «var» за пределы функций/методов. Мне кажется, это невозможно. Вернее, возможно, но только для private-элементов. Да и не нужно это.
4) Проваливающийся switch. Это ужасно. =) Подобная констукция специально не используется в C#, так как подобное поведение нужно нечасто, зато ошибки из-за этого происходят постоянно. Самый правильный вариант в этом случае, я считаю, использовать оператор «goto xxx;» вместо «break;», где xxx — метка следующего кейса (в этом случае это не антипаттерн).
5) Использовать в switch не «константные варианты». — Вот это и правда полезно.
6) List<var> SomeList = new List<string>(); — Не вижу смысла.
7) [NotNull] атрибут для типов данных. — А как это реализовать? Автоматически вставлять проверку на null при каждом присваивании? Можно, но тут, как мне кажется, много нюансов…
8) Интегрировать частично возможности Spec# — какие? =)
9) Mixing как в Ruby — не знаком с Ruby, но mixin-ы — это круто =)
10) Мета-программирование на стадии компиляции. — Однозначно «Да»!
Что не хватает мне:
1) Не понял =)
2) PNG сжатие, оно есть но не работает. — это скорее вопрос к разработчикам GDI+
3) Убрать «прикол», когда нужно каждый раз сохранять JPG с качеством 75%, ибо если 100%, то эффекта нет, а размер файла растет. — не сталкивался, не знаю.
4) В WinForms (в WPF не пробовал) возможность работать объекту на форме (контролу) в другом потоке. — Прямой путь к deadlock-ам. Думаете, это случайно так сделали?
5) Это относится к Visual Studio, но напишу: Дизайнер WCF конфигурации. Дайте! Да! =)