Comments 86
CgСпабо за информацию. только кат поставьте.
хорошо собрал заказы… вашими слова да разработчикам в уши :)
хм, zabr все твои требования не к языку относятся, а к фреймворку
а что там с png? где не работает?
хм, zabr все твои требования не к языку относятся, а к фреймворку
а что там с png? где не работает?
Да мои требования к фреймворку относятся, но ведь с обновлением C# спецификации, попутно будет обновление плафтормы с не сильно отдаленном будущем, вдруг увидят :)
насчет JPG и 75% это можно почитать исходники Paint .Net они помоему в том месте то ли 3 то ли 4 коммента оставили.
по поводу сжатие в PNG:
когда сохраняешь картинку используя EncoderParameter-ы, то если стоит сжатие например:
myEncoderParameter = new EncoderParameter(myEncoder, long)EncoderValue.CompressionLZW);
дословно не поню вылезло это где то года полтора назад.
То оно просто ни на что не влияет в некоторых форматах.
насчет JPG и 75% это можно почитать исходники Paint .Net они помоему в том месте то ли 3 то ли 4 коммента оставили.
по поводу сжатие в PNG:
когда сохраняешь картинку используя EncoderParameter-ы, то если стоит сжатие например:
myEncoderParameter = new EncoderParameter(myEncoder, long)EncoderValue.CompressionLZW);
дословно не поню вылезло это где то года полтора назад.
То оно просто ни на что не влияет в некоторых форматах.
Довольно интересно. А вы не могли бы пояснить пункты 1 и 2, я не понял что значит «Опциональные параметры» и «Опциональное ключевое слово»
да конечно, «Опциональные параметры в функциях и методах. „ это означает что мы например создаем функцию/метод с двумя входящими параметрами:
а затем вызвали бы ее в другом месте:
DoSmth(1);
DoSmth(«1»);
то в обоих случаях мы увидели бы «test», и удалось бы избежать перегрузок:
Более расширено об этом написали тут и тут
[Optional Parameters]
private void DoSmth(string SomeText, int SomeValue)
{
Console.WriteLine(“test»)
}
а затем вызвали бы ее в другом месте:
DoSmth(1);
DoSmth(«1»);
то в обоих случаях мы увидели бы «test», и удалось бы избежать перегрузок:
[Optional Parameters]
private void DoSmth(string SomeText)
{
Console.WriteLine(«test»)
}
[Optional Parameters]
private void DoSmth(int SomeValue)
{
Console.WriteLine(«test»)
}
Более расширено об этом написали тут и тут
Думаю это внесёт только путаницу.
C# изначально делался таким образом, чтобы нельзя было допустить какую-нибудь глупую ошибку, как например в случае с проваливающимся switch`ем.
C# изначально делался таким образом, чтобы нельзя было допустить какую-нибудь глупую ошибку, как например в случае с проваливающимся switch`ем.
Абсолютно согласен. На Хабре уже кто-то писал подобную мысль: C# изначально был очень строгим, но постепенно движется в сторону PHP (как бы это ни смешно звучало), а РНР — наоборот, в сторону строгости изначального C#.
А «проваливающийся switch» — это точно кошмар, надеюсь, ума хватит этого не сделать (вряд ли сделают, так как тогда слишком сложно станет переносить код с предыдущих версий).
А «проваливающийся switch» — это точно кошмар, надеюсь, ума хватит этого не сделать (вряд ли сделают, так как тогда слишком сложно станет переносить код с предыдущих версий).
Вы немного переврали синтаксис, который использовался в той статье, и в итоге понять, что имелось ввиду стало сложнее, в предложенных там вариантах аттрибуты были перед агрументом, а не перед функцией. Но по-мойму использовать аттрибуты в данном случае не правильно, так как схожий механизм уже применяется в .net'е — params. Поэтому я думаю, что возможном вариантом будет следующий:
void foo(int a, params int b = 666, params string text=«hell») {… }
Вызов метода следующий: foo(12, test:=«paradise») или foo(12, b:= 1);
Хотя все предсказания, которые вы дали не воспринимаются, как единое целое, так как в отличии от перехода к 3-ей версии, в которой все изменения (статические расширения классов, аннонимные классы, var) были нацелены на реализацию LINQ, за этими изменениями не чувствуется цельное ядро.
void foo(int a, params int b = 666, params string text=«hell») {… }
Вызов метода следующий: foo(12, test:=«paradise») или foo(12, b:= 1);
Хотя все предсказания, которые вы дали не воспринимаются, как единое целое, так как в отличии от перехода к 3-ей версии, в которой все изменения (статические расширения классов, аннонимные классы, var) были нацелены на реализацию LINQ, за этими изменениями не чувствуется цельное ядро.
с C# 3.0 появилось ключевое слово var
( msdn.microsoft.com/en-us/library/bb383973.aspx)
и довольно многие разработчики считаю что его можно сделать опциональным (не обязательным), т.к все равно область видимости у переменных этого не выходит за рамки методов/функций.
например вместо такого:
private void DoSmth()
{
var SomeIntrestingString = «test»;
}
писать так:
private void DoSmth()
{
SomeIntrestingString = «test»;
}
( msdn.microsoft.com/en-us/library/bb383973.aspx)
и довольно многие разработчики считаю что его можно сделать опциональным (не обязательным), т.к все равно область видимости у переменных этого не выходит за рамки методов/функций.
например вместо такого:
private void DoSmth()
{
var SomeIntrestingString = «test»;
}
писать так:
private void DoSmth()
{
SomeIntrestingString = «test»;
}
Довольно опасная штука. Чревато ошибками.
Ужасно. Пример:
Вопрос на засыпку: что выдаст эта функция?
Ответ: ошибку на стадии компиляции. Потому как в строке someVariаble = «111» в имени переменной вторая буква «а» — русская =)
А если можно будет без var определять переменные — такие ошибки только в рантайме поймаются, и отловить их будет не так просто.
private void DoSmth()
{
var someVariable = "";
someVariаble = "111";
if (someVariable != "")
Console.Write("test successful!!!");
else
Console.Write("test failed...");
}
Вопрос на засыпку: что выдаст эта функция?
Ответ: ошибку на стадии компиляции. Потому как в строке someVariаble = «111» в имени переменной вторая буква «а» — русская =)
А если можно будет без var определять переменные — такие ошибки только в рантайме поймаются, и отловить их будет не так просто.
Нет, имхо, ни в коем случае нельзя вводить такое «упрощение»!
Объявление переменной задает нам область видимости в любом случае, var это или не var. В JavaScript, где как раз разрешено опускать var'ы, объявление переменной без var приводит к ее определению в глобальной области видимости. Народу на этом погорело, думаю, достаточно. Я однажды потратил чуть ли не час времени на диагностику ошибки, возникшей из-за переменной без var'а (кажется, в названии аргумента функции была опечатка, и первое обращение к «аргументу» приводило к созданию переменной)!
Да, var'ы не могут выходить за пределы метода. Но программисты хотят…
Кроме того, даже внутри метода могут быть различные области видимости. Не для того ли их придумали, чтобы потом вот так отменять?
Объявление переменной задает нам область видимости в любом случае, var это или не var. В JavaScript, где как раз разрешено опускать var'ы, объявление переменной без var приводит к ее определению в глобальной области видимости. Народу на этом погорело, думаю, достаточно. Я однажды потратил чуть ли не час времени на диагностику ошибки, возникшей из-за переменной без var'а (кажется, в названии аргумента функции была опечатка, и первое обращение к «аргументу» приводило к созданию переменной)!
Да, var'ы не могут выходить за пределы метода. Но программисты хотят…
3. Вывести «var» за пределы функций/методов.
Кроме того, даже внутри метода могут быть различные области видимости. Не для того ли их придумали, чтобы потом вот так отменять?
ээээ хватит минусовать, не я этот «var» придумал :)))
Чего хотят программисты:
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) Опциональные параметры в функциях и методах — это как?
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 конфигурации. Дайте! Да! =)
Вот тут автор рассказывает о некоторых возможностях частично из Boo,
частично из Spec#, которые он хотел бы видеть в C# 4.0
www.codinginstinct.com/2008/05/spec-and-ideas-for-c-40.html
частично из Spec#, которые он хотел бы видеть в C# 4.0
www.codinginstinct.com/2008/05/spec-and-ideas-for-c-40.html
насчет 1 пункта «Чего не хватает мне»
что именно? зачем это нужно? например для создания медиа коллекций.
что именно? зачем это нужно? например для создания медиа коллекций.
как в известной песне:
«всё не просто в этом мире,
но всё исправит си-четыре, си-четыре».
«всё не просто в этом мире,
но всё исправит си-четыре, си-четыре».
Хочу попросить помощи у людей. Я написал статью на тему «Использование провайдеров компиляции в Asp.net», но мне не хватает кармы, чтобы её опубликовать.
Добавил :)
Было бы интересно почитать какие преимущества дает.
Было бы интересно почитать какие преимущества дает.
Вот статья автора: habrahabr.ru/blogs/net/40047/
Всем большое спасибо!
Всем большое спасибо!
Мне очень нравится синтаксис C#, и я бы очень хотел писать на нем сайты, как на php. Просветите меня если есть такая возможность (asp.net не считается)
Так можно в принципе делать, но я бы вам не советовал.
Грубо говоря вы можете писать страницы так:
файл Default.aspx:
А можно еще и писать все в событии Page_Load(),
или создать файл Global.asax и написать все классы в нем
со всеми методами, инферфейсами, функцифми и проч., но это все Terrible Practies,
так делать НЕ СЛЕДУЕТ! Имхо.
Грубо говоря вы можете писать страницы так:
файл Default.aspx:
<%
private void Page_Load(object sender, EventArgs e) {
{
DoSmth();
}
private void DoSmth()
{
Respone.Write(«Hello World»)
}
%>
А можно еще и писать все в событии Page_Load(),
или создать файл Global.asax и написать все классы в нем
со всеми методами, инферфейсами, функцифми и проч., но это все Terrible Practies,
так делать НЕ СЛЕДУЕТ! Имхо.
Извините если не уловил Вашу мысль.
Как бы, охота на серваке под линуксом, делать сайты на C#. Или типа синтаксис C#?
Вам поможет это: www.mono-project.com/ASP.NET и это: www.mono-project.com/Mod_mono
Чего не хватает, imho, так это ковариаций и контрвариаций параметра типов обобщений, которые, кстати, поддерживаются на уровне IL, но не поддерживаются в самом С#.
В java у нас есть подстановочные типы вроде <? extends Foo> и <? super Foo>, в С# хотелось бы иметь нечто подобное…
В java у нас есть подстановочные типы вроде <? extends Foo> и <? super Foo>, в С# хотелось бы иметь нечто подобное…
насчет
5. Это относится к Visual Studio, но напишу: Дизайнер WCF конфигурации. Дайте!
меню tools\WCF Service Configruration Editor — это точно не то что Вам нужно?
5. Это относится к Visual Studio, но напишу: Дизайнер WCF конфигурации. Дайте!
меню tools\WCF Service Configruration Editor — это точно не то что Вам нужно?
Из «чего не хватает программистам» согласен только с пятым. По поводу остального — не превращайте C# в JavaScript!
Но ничего, всё будет хорошо. Как по заявлениям MS, так и на практике, сильная сторона .NET — строгая (очень строгая, да!) типизация. Бардак с var-ами и «опциональными параметрам» не пройдёт. Да, и использование «Falling switch» — плохое, очень плохое программирование! И «необходимость» использовать это свидетельствует лишь об ошибках проектирования. Всегда. Так и до goto докатимся.
Про Ваше. Досадные баги, да, исправят уж наверно. К исключениям при отказе в доступе хотелось бы добавить вечно валящееся исключение при использовании HttpRequest и HttpResponse, если сервер возвращает 404. Беда куда меньшая, чем при работе с файлами, но тоже лишние затраты ресурсов и некрасивый/неудобный код с логикой работы в try/catch.
А зачем контролу полностью работать в отдельном потоке? Пусть себе в одном потоке с формой лежит, а результаты каких-то вычислений из потока отображает Invoke-ом.
Но ничего, всё будет хорошо. Как по заявлениям MS, так и на практике, сильная сторона .NET — строгая (очень строгая, да!) типизация. Бардак с var-ами и «опциональными параметрам» не пройдёт. Да, и использование «Falling switch» — плохое, очень плохое программирование! И «необходимость» использовать это свидетельствует лишь об ошибках проектирования. Всегда. Так и до goto докатимся.
Про Ваше. Досадные баги, да, исправят уж наверно. К исключениям при отказе в доступе хотелось бы добавить вечно валящееся исключение при использовании HttpRequest и HttpResponse, если сервер возвращает 404. Беда куда меньшая, чем при работе с файлами, но тоже лишние затраты ресурсов и некрасивый/неудобный код с логикой работы в try/catch.
А зачем контролу полностью работать в отдельном потоке? Пусть себе в одном потоке с формой лежит, а результаты каких-то вычислений из потока отображает Invoke-ом.
Я бы сказал даже, что в общем случае использование оператора switch это моветон и анахронизм:)
Не первый раз слышу подобное.
Чем же пользоваться, не просветите?
Чем же пользоваться, не просветите?
Свич нужен, но только в самом низу дерева методов. Остальное необходимо разруливать фабриками и прочим.
Это моё имхо, может товарищ это и имел в виду…
Это моё имхо, может товарищ это и имел в виду…
Ну как же… Вариантов много, от ситуации зависит. Например в некоторых случаях имеет смысл заменить switch полиморфизмом. Довольно часто бывает целесообразно заменить ветвления на логические и вычислительные операции.
Если первый раз слышите, советую обратиться, например к Фаулеру.
Если первый раз слышите, советую обратиться, например к Фаулеру.
Ну, к примеру, практическая задача. Имеем запрос к серверу и варианты ответа, типа 404 и прочих. В зависимости от ответа делаем абсолютно разные вещи. Как быть без switch? Обойтись-то можно в принципе, но нагородив кучу кода с единственной целью «нахрен switch». Во всяком случае, красивых решений не вижу.
Ну или, как уже спросил у оратора ниже, что делать с конечным автоматом?
Я ни в коем случае не спорю, хочется понять просто современные, так сказать, тенденции.
Ну или, как уже спросил у оратора ниже, что делать с конечным автоматом?
Я ни в коем случае не спорю, хочется понять просто современные, так сказать, тенденции.
Йех, а зайчем тут свич вообще? Что он будет делать?
ну дык…
switch(serverResponse)
{
case 200:
// тут что-то одно
break;
case 404:
// тут что-то абсолютно другое
break;
}
и таких «ответов Чемберлену» у нас наберётся, к примеру, штук 15. Пример утрирован, обычно нужно «200» и «всё остальное», но всё же?
switch(serverResponse)
{
case 200:
// тут что-то одно
break;
case 404:
// тут что-то абсолютно другое
break;
}
и таких «ответов Чемберлену» у нас наберётся, к примеру, штук 15. Пример утрирован, обычно нужно «200» и «всё остальное», но всё же?
А что вы собираетесь делать в этом свитче? В вашем случае я вижу if(ResponseProcessor.IsSucceeded(response)){...} else Log.HttpError(response); Как-то так…
Внимательнее.
> и таких «ответов Чемберлену» у нас наберётся, к примеру, штук 15. Пример утрирован, обычно нужно «200» и «всё остальное», но всё же?
А что делать — не важно. К примеру, если 200, качаем картинку по урлу, если 404, пробуем что-то в урле изменить, если 400 — меняем что-то в запросе, если 408 — ждём 5 минут…
> и таких «ответов Чемберлену» у нас наберётся, к примеру, штук 15. Пример утрирован, обычно нужно «200» и «всё остальное», но всё же?
А что делать — не важно. К примеру, если 200, качаем картинку по урлу, если 404, пробуем что-то в урле изменить, если 400 — меняем что-то в запросе, если 408 — ждём 5 минут…
Если пофантазировать, вполне можно придумать какую-нибудь хэш-таблицу функторов, где ключем будет код ответа сервера.
Чем это _принципиально_ отличается от switch?
Вообще говоря всем:) Вопрос можно конкретизировать?
Ну, чем таблица со столбцами «ключ» и «что делать» отличается от switch, который также опередляет действие в зависимости от значения ключа?
Отличие в реализации. Если вариантов много и каждый из вариантов предполагает выполнение «немаленького» объема кода, может быть целесообразнее использовать хэш. Тем более что, хэш позволяет использовать те самые «неконстантные» варианты. Созданные функторы можно использовать отдельно, вообще конструкция получается гораздо более модульной и повторноиспользуемой.
Вобщем-то я не призываю полностью отказаться от switch. В некоторых случаях он вполне может быть полезен; суть в том, что зачастую могут присутствовать более удачные варианты.
Вобщем-то я не призываю полностью отказаться от switch. В некоторых случаях он вполне может быть полезен; суть в том, что зачастую могут присутствовать более удачные варианты.
Даже с пятым не согласен — switch вообще редко нужнен (по крайней мере, должен быть редко нужен), а с неконстантными параметрами — и подавно, так и видятся горы индо-кода с этим нововведением. По мне, так даже введение var — уже спорный шаг. Мне вообще C# 2.0 очень даже нравится =)
Про mixings чего-т не очень понял — это типа когда отдельно пишем методы, а потом при создании класса просто набираем нужные уже симплементированные?
Про mixings чего-т не очень понял — это типа когда отдельно пишем методы, а потом при создании класса просто набираем нужные уже симплементированные?
Про mixings тоже сути не уловил. Но если это так, как Вы написали — это отвратительно!
Про индокод, пожалуй, Вы правы. Неконстантные case-ы хотелось только, если константы были, ну, не совсем константами :). Известны становились, скажем так, в момент запуска проги, ситуация крайне редкая и вполне решаемая без switch. Но позволить в рантайме менять то, что в case-ах и строить на этом логику… Ужас будет.
И всё же, за что ж switch так не любят? Как красиво, без кучи «if-else-if» нормально реализовать, скажем, модель конечного автомата? Бывает нужна нередко.
И всё же, за что ж switch так не любят? Как красиво, без кучи «if-else-if» нормально реализовать, скажем, модель конечного автомата? Бывает нужна нередко.
Смотря какой конечный автомат, в случае с респонзами сервера, например, хеш-таблица с функторами и методом для добавления обработчика на произвольный код ошибки не самый плохой вариант. Например, если логика работы с сервером находится в библиотеке, то при добавлении обработки ответа из тех, которые в свитче отнесены ко «всему остальному», не придется лезть в код этой библиотеки.
Ну, в случае с респонзами сервера, это совсем даже не автомат :).
В атомате нужно хранить текущее состояние, и иметь возможность в обработчиках его менять. В случае хэш-таблицы это можно сделать или глобальной переменной, что ужасно, или передавать состояние по ссылке, что лучше. Имхо всё это не красивей обычного switch, но это имхо.
В любом случае суть понятна, спасибо!
В атомате нужно хранить текущее состояние, и иметь возможность в обработчиках его менять. В случае хэш-таблицы это можно сделать или глобальной переменной, что ужасно, или передавать состояние по ссылке, что лучше. Имхо всё это не красивей обычного switch, но это имхо.
В любом случае суть понятна, спасибо!
Свитч в отдельных случаях — действительно удобен, но это случаи «3-5 вариантов, в каждом строка-две с элементарными действиями», в любом другом скорее всего есть более красивое и универсальное решение.
Насчет mixin-ов (g на конце там, кстати, нет) — и правда можно было бы в C# кое-что упростить.
В нем ведь нет множественного наследования на уровне языка. Поэтому, если все же надо реализовать такую возможность, приходится прибегать к композиции:
Надоедает писать одно и то же по десятку раз. Жаль, что нет синтаксического сахара для композиции, например:
Хотя не факт, что такое желание возникает у достаточно большого числа разработчиков, чтобы авторам компилятора был смысл мучаться.
В нем ведь нет множественного наследования на уровне языка. Поэтому, если все же надо реализовать такую возможность, приходится прибегать к композиции:
class MyClass
{
private AnotherClass anotherObject;
void SomeMethod() { anotherObject.SomeMethod(); }
int GetSomeResult() { return anotherObject.GetSomeResult(); }
...
Надоедает писать одно и то же по десятку раз. Жаль, что нет синтаксического сахара для композиции, например:
class MyClass
{
private AnotherClass anotherObject;
delegate SomeMethod, GetSomeResult to anotherObject;
Хотя не факт, что такое желание возникает у достаточно большого числа разработчиков, чтобы авторам компилятора был смысл мучаться.
про «HttpRequest и HttpResponse» полностью поддерживаю,
про Invoke — да так у меня счас в одном приложении и работает,
но такой тонкий момент что если там например флеш играется или Directx,
а одновременно мне еще нужно обновлять другой контрол, то возникают задержки иногда маленькие.
про Invoke — да так у меня счас в одном приложении и работает,
но такой тонкий момент что если там например флеш играется или Directx,
а одновременно мне еще нужно обновлять другой контрол, то возникают задержки иногда маленькие.
1. Опциональные методы в C# приведут codebase в помойку, в которой находятся PHP, Python и иже с ними. Также см. п. 1.
2,3. Ключевик var вообще ограничить максимально, чтобы _только_ в анонимных классах был.
6. См. 2,3.
2,3. Ключевик var вообще ограничить максимально, чтобы _только_ в анонимных классах был.
6. См. 2,3.
Тут бы до 3 и 3,5 добраться, а вы про 4й уже говорите.
Если серьезно, то не все, что Вы написали может быть внедрено в C#. Об этом говорят и предыдущие комментарии и опыт Microsoft.
Спорить и разводить холивары по поводу того, что нужно, а что нет не буду, все покажет время. Это как эволюция: выживет сильнейший [язык программирования]. И синтакисис его будет таким, каким его сделает эта «эволюция».
Если серьезно, то не все, что Вы написали может быть внедрено в C#. Об этом говорят и предыдущие комментарии и опыт Microsoft.
Спорить и разводить холивары по поводу того, что нужно, а что нет не буду, все покажет время. Это как эволюция: выживет сильнейший [язык программирования]. И синтакисис его будет таким, каким его сделает эта «эволюция».
Случайно пропустил и не добавил «пре-заключение», оно после зеленой линии идет.
5,6 можно обобщить: хочется полноценный pattern matching :)
Я очень надеюсь, что инжинеры из майкрософт будут поддерживать профессиональный стиль C#, сохранять в нем лучшие черты C++, и в то же время избегать появления в нем черт скриптовых языков. Если же случиться обратное, то придется смотреть на джава для решения бизнес-задач.
К тому же, благо .NET позволяет, всегда можно иметь отдельный язык для массовой категории разработчиков со средней квалификацией (опытом).
К тому же, благо .NET позволяет, всегда можно иметь отдельный язык для массовой категории разработчиков со средней квалификацией (опытом).
Всё верно — как на JVM есть консервативная, простая, однозначная и проверенная Java, а так же новомодные Groovy & Scala — поля для экспериментов. Те, кто пишут в блогах и требуют перемен — лишь малый процент всех разработчиков, пользующихся технологией. И пока не будет реальной причины для смены/обновления языка — делать этого не надо.
Чего хотят программисты:Этого хотят не программисты, а «пэ-ха-пэшники».
1. Опциональные параметры в функциях и методах.
2. Сделать опциональным ключевое слово «var», все равно будем отталкиваться от названия переменной.
3. Вывести «var» за пределы функций/методов.
4. Проваливающийся switch (пример)
*имею в виду не конкретный язык, а культуру его использования.
«Чего хотят программисты» позвольте поинтерисоваться откуда такие данные? Потому как по мне, так это всё незначительные и малоиспользуемые вещи, которые, по большому счёту, нафиг не нужны большинству програмистов.
из различных статей и блогов, часть из них можно найти по запросам типо:
www.google.ru/search? q=C%23+4.0+wishlist
www.google.ru/search? q=C%23+4.0+wishlist
Ну, вот я посмотрел одну из первых ссылок (http://channel9.msdn.com/posts/TheChannel9Team/Eric-Gunnerson-How-do-you-design-new-features-for-C/? CommentID=414710) и там гораздо более продуманные и сложные советы (коменты), в отличие от очередной пачки syntax sugar из этой статьи.
Или вот ещё — pico.vub.ac.be/~wdmeuter/RDL04/papers/Meijer.pdf ответ на вопрос «Dynamic vs Static typing».
2. Этого не будет, просто потому, что это усложнит компилятор без всякого выигрыша для программистов.
4. Этого точно не будет, это увеличивает вероятность ошибок, и специально вырезано из языка.
4. Этого точно не будет, это увеличивает вероятность ошибок, и специально вырезано из языка.
По мелочам — что бы хотелось мне.
Лексический сахар:
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. Наверняка много чего забыл. Сразу всё сложно вспомнить.
Лексический сахар:
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. Наверняка много чего забыл. Сразу всё сложно вспомнить.
1) Константный switch. Кажется, идея заимствована из языка D, хотя не уверен.
Суть в том, что если перед switch стоит слово const, то внутри switch-a должны быть рассмотрены все случаи ветвления. Иначе происходит ошибка компиляции.
Идея заимствована из ML (не то чтобы оно там впервые появилось, но нынешний вид в популярных ФЯП приняло тогда), по-человечески называется pattern matching :-)
В C# нет структур данных, с которыми развернулась бы мощь PM, но можно вспомнить active patterns из F#.
Не пойму, накой чёрт я должен писать «using System.Linq;» в каждом файле, где использую Linq?
В VB.NET есть что-то в стиле «Solution-Wide Imports» (Imports — аналог using из C#). Ужос аццкий. Никогда не поймешь, почему вдруг у тебя вместо одного класса появляется совершенно неожиданный его однофамилец.
жаль что автовставки линка и других неиспользуемых неймспейсов не настраиваются, как и референсы. ((
в C# есть по сути алиасы также работающие, если не ошибаюсь, да ужос, но иногда бывает что совпадаешь с названием класса из самого фреймворка и приходится юзать, нет ну можно и полный путь каждый раз но не айс…
правда у меня за года 2 программирования на шарпе и на вб.нет такое встречалось ну раза 3 максимум.
в C# есть по сути алиасы также работающие, если не ошибаюсь, да ужос, но иногда бывает что совпадаешь с названием класса из самого фреймворка и приходится юзать, нет ну можно и полный путь каждый раз но не айс…
правда у меня за года 2 программирования на шарпе и на вб.нет такое встречалось ну раза 3 максимум.
По долгу службы я периодами пишу как на C#, так и на JavaScript. И я полностью прочувствовал все прелести и недостатки динамического языка. И методы с необязательными параметрами (в JavaScript нет перегрузок — поэтому все так) и, по сути, отсутствующую типизацию.
В C# скучно. Там не приходится вручную отслеживать каждый аргумент метода до его источника, чтобы понять, какую структуру он имеет. Или, перед тем, как вызывать метод, сначала нужно понять, объект какой структуры этот метод ожидает получить…
Необязательные параметры? Ну пожалуйста, как будем рулить такую штуку?
Необязательный var? Я уже писал в комментарии — как тогда будем определять область видимости?
Выводить var за пределы функций? Зачем? Делать так:
или так:
Первый вариант, криво, но реализуется возвратом object. Для второго придумали Generic Methods.
Проваливающийся switch — штука, реально полезная крайне редко. Намного чаще получается без нее обходиться.
Лично мне было бы интересно увидеть в C# 4.0 не тупое увеличение энтропии, а реально полезные штуки. Помнится, на RSDN занимались разработкой C# со средствами метапрограммирования. Не знаю, жив ли сейчас проект, но интересных решений в нем было достаточно.
Хотелось бы увидеть IL-ассемблерные вставки. Не для понтов, а в качестве замены медленному Reflection. Плюс поддержку более широкого набора типов, которые могут быть использованы для свойств атрибутов (хотя я всего пару раз натыкался на это ограничение).
В C# скучно. Там не приходится вручную отслеживать каждый аргумент метода до его источника, чтобы понять, какую структуру он имеет. Или, перед тем, как вызывать метод, сначала нужно понять, объект какой структуры этот метод ожидает получить…
Необязательные параметры? Ну пожалуйста, как будем рулить такую штуку?
[OptionalParameters]
void SomeFunc(string s, object o) { ... }
...
SomeFunc("Hello world");
SomeFunc(null);
Необязательный var? Я уже писал в комментарии — как тогда будем определять область видимости?
Выводить var за пределы функций? Зачем? Делать так:
public var SomeFunc() { ... } // верни мне не знаю что
или так:
void SomeFunc(var arg0, var arg1) { ... } // возьми не знаю что и сделай что-нибудь
Первый вариант, криво, но реализуется возвратом object. Для второго придумали Generic Methods.
Проваливающийся switch — штука, реально полезная крайне редко. Намного чаще получается без нее обходиться.
Лично мне было бы интересно увидеть в C# 4.0 не тупое увеличение энтропии, а реально полезные штуки. Помнится, на RSDN занимались разработкой C# со средствами метапрограммирования. Не знаю, жив ли сейчас проект, но интересных решений в нем было достаточно.
Хотелось бы увидеть IL-ассемблерные вставки. Не для понтов, а в качестве замены медленному Reflection. Плюс поддержку более широкого набора типов, которые могут быть использованы для свойств атрибутов (хотя я всего пару раз натыкался на это ограничение).
1.Не плохо было бы реализовать возможность использования yield return внутри анонимных методов и лямбды
2.Еще хотелось бы иметь возможность в методе уметь использовать и yield return и return, а то в рекурсивных методах IEnumerable приходится еще foreach городить по результату
2.Еще хотелось бы иметь возможность в методе уметь использовать и yield return и return, а то в рекурсивных методах IEnumerable приходится еще foreach городить по результату
Почему невозможно?
Мы же можем писать:
Почему нельзя сделать вот так:
понятно, что сахар) но даже в таком простом кусочке стало гораздо понятнее, что происходит
P.S. За ссылку спасибо.
IEnumerable<T> foo(TreeNode node){
foreach (var node in node.Children){
var nodes = foo(node)
foreach (var n in node.Children){
yield return n;
}
yield return node;
}
}
* This source code was highlighted with Source Code Highlighter.Почему нельзя сделать вот так:
IEnumerable<T> foo(TreeNode node){
foreach (var node in node.Children){
yield! return foo(node)
yield return node;
}
}
* This source code was highlighted with Source Code Highlighter.понятно, что сахар) но даже в таком простом кусочке стало гораздо понятнее, что происходит
P.S. За ссылку спасибо.
Sign up to leave a comment.
Чего мы ждем от C# 4.0