Комментарии 76
>Умный switch
может, стоит использовать паттерн Strategy или Command?
может, стоит использовать паттерн Strategy или Command?
>// elsewhere: item1 is a string, item2 is an int, item3 is a double.
>var item1, item2, item3 = ReturnMyTuple();
а это вообще от ПХПшников, похоже:))
list($a, $b, $c) = mysql_fetch_row($res);
>var item1, item2, item3 = ReturnMyTuple();
а это вообще от ПХПшников, похоже:))
list($a, $b, $c) = mysql_fetch_row($res);
В Nemerle и F# кортежи поддерживаются внутри языка. Синтаксис таков:
Nemerle:
def (x, y ,z) = GetTuple();
F#:
let name, age, color = get_person (… );;
Nemerle:
def (x, y ,z) = GetTuple();
F#:
let name, age, color = get_person (… );;
Да pattern matching очень хотелось бы видеть хотя бы в таком виде.
Кстати для Mono есть патчи, реализующие это tirania.org/blog/archive/2009/Dec-23.html
Кстати для Mono есть патчи, реализующие это tirania.org/blog/archive/2009/Dec-23.html
Tuple есть во многих продвинутых языках… Даже lua позволяет возвращать два значения (хотя это и не совсем tuple).
Это от Питона.
def func():
return 1, 2, 3
a, b, c = func()
def func():
return 1, 2, 3
a, b, c = func()
Мне умный switch третьего типа совсем не понравился:
switch (aString)
{
case .IsNullOrEmpty():
…
case .Length > 100:
…
case .Contains(«foo»):
…
}
Это же говнокодом попахивает, CLR для каждого case придется вызывать метод, а это уже не быстрый switch, а просто синтаксический сахар над IFами.
switch (aString)
{
case .IsNullOrEmpty():
…
case .Length > 100:
…
case .Contains(«foo»):
…
}
Это же говнокодом попахивает, CLR для каждого case придется вызывать метод, а это уже не быстрый switch, а просто синтаксический сахар над IFами.
Хотел бы иметь в арсенале некоторые встроенные подходы аспектно-ориентированного программирования.
Жду поддержку мета-программирования.
>как это сейчас в Java
хватит слизывать все с божественного языка!
хватит слизывать все с божественного языка!
>>возможность обрабатывать файлы с длинными именами
Это случайно не os-depend функциональность?
Это случайно не os-depend функциональность?
Видел список нововведений C# 4.0 Задавал себе вопрос- неужели это кому то надо?
В итоге понравилось, применяю.
Сейчас смотрю на список, что Вы предлагаете и опять тоже самое: Неужели кому то надо?
Интересно, примут ли эти новинки… То что предлагаете по части Tuple лично меня пугает.
Нет строгости как то!
В итоге понравилось, применяю.
Сейчас смотрю на список, что Вы предлагаете и опять тоже самое: Неужели кому то надо?
Интересно, примут ли эти новинки… То что предлагаете по части Tuple лично меня пугает.
Нет строгости как то!
Отчасти согласен. Но когда-то я не мог понять зачем необходимы лямбда-выражения — они казались очень сложными и не понятными. А сейчас не знаю, чтобы без них делал.
Tuple нужны. Бывает нужно вернуть два-три значения и приходится изворачиваться, чтобы выглядело красиво, а с tuples все красиво выглядит, если синтаксис не перегружен.
Я не спорю что Tuble нужны. Меня шокирует вот такие способы
public string, int, double ReturnMyTuple()
{
return «Hello World!», 42, 4.2;
}
Функция возвращающая несколько типов, не объединенных в один тип tuple на мой взгляд убивает строгость.
public string, int, double ReturnMyTuple()
{
return «Hello World!», 42, 4.2;
}
Функция возвращающая несколько типов, не объединенных в один тип tuple на мой взгляд убивает строгость.
НЛО прилетело и опубликовало эту надпись здесь
Кортежи (tuple) — это и есть та самя сущность, чтобы не создавать мелкий класс, который нужен только здесь и там, где вызывается. В результате получаем удобство и скорость разработки.
Конечно, когда вы возвращаете Point, то нужен класс, потму что, скорее всего, потребуются какие-то методы.
А когда вы возвращаете текстовое сообщение и флаг критичности сообщения, то обычно можно обойтись и кортежем.
Конечно, когда вы возвращаете Point, то нужен класс, потму что, скорее всего, потребуются какие-то методы.
А когда вы возвращаете текстовое сообщение и флаг критичности сообщения, то обычно можно обойтись и кортежем.
Некоторые «пожелания» очень сомнительны.
Как минимум мне не хватает алгебраических типов данных и pattern-matching'а.
Если мечтать, то хочу метапрограммирование как в Nemerle.
Точно известно, что можно будет использовать compiler-as-a-service, правда, благодаря ребятам из mono это возможно и сейчас.
Если мечтать, то хочу метапрограммирование как в Nemerle.
Точно известно, что можно будет использовать compiler-as-a-service, правда, благодаря ребятам из mono это возможно и сейчас.
По-моему, синтаксические красявости убивают понимание.
Апофеоз краткости — это c++, в котором в одну строку можно столько всякой логики засунуть (с циклами, проверками, инкрементированием, побитовыми операциями), что смысл выполняемого кода пропадает совсем.
То же касается и Ваших предложений по Tuple и var.
Например, в случае
var value = someObject.Value;
метод без скобок — это указатель на метод, который уже сейчас можно присваивать делегату, но уж никак не вызов метода без параметров, для меня по крайней мере.
Апофеоз краткости — это c++, в котором в одну строку можно столько всякой логики засунуть (с циклами, проверками, инкрементированием, побитовыми операциями), что смысл выполняемого кода пропадает совсем.
То же касается и Ваших предложений по Tuple и var.
Например, в случае
var value = someObject.Value;
метод без скобок — это указатель на метод, который уже сейчас можно присваивать делегату, но уж никак не вызов метода без параметров, для меня по крайней мере.
Спасибо за комментарий, но справедливости ради нужно заметить, что моих предложений здесь нет — я всего лишь отобрал интересные, на мой взгляд, пожелания.
А вот то, что можно кучу логики запихнуть в одну строку не всегда оправдано — всегда нужно сохранять компромисс между краткостью и читабельностью.
А вот то, что можно кучу логики запихнуть в одну строку не всегда оправдано — всегда нужно сохранять компромисс между краткостью и читабельностью.
а по поводу Enum в C# — меня реализация устраивает, зато смущает реализация аннотаций в Java (они же атрибуты в C#) — через @interface.
Хочу managed компилятор и compiler as service.
1. Множественное наследование, виртуальные методы-расширения — это адский идиотизм, убивать сразу тех, кто даже подумывает чтобы ввести это с C# или Java.
2. В случае с if (x in [1, 2, 4..8, 10]) { } вы просто будете подталкивать говнокодеров к хардкоду, а не выносить параметры приложения в конфиги.
3. Автофлаги приведут к неподдерживаемому коду и адской несовместимости между версиями приложения.
4. про ??? я уже молчу. а чё, давайте введём ???? и ?????
ну и далее по списку…
из полезного я увидел только дополнительные ограничения в дженериках. вот этого да, действительно не хватает.
2. В случае с if (x in [1, 2, 4..8, 10]) { } вы просто будете подталкивать говнокодеров к хардкоду, а не выносить параметры приложения в конфиги.
3. Автофлаги приведут к неподдерживаемому коду и адской несовместимости между версиями приложения.
4. про ??? я уже молчу. а чё, давайте введём ???? и ?????
ну и далее по списку…
из полезного я увидел только дополнительные ограничения в дженериках. вот этого да, действительно не хватает.
Хочется тупо пометить свойство аттрибутом [NotifyPropertyChanged] и не писать в каждом set'e OnPropertyChanged(«XXX») без AOP. (synt. sugar)
Даешь компактный синтаксис для создания массивов как в Actionscript3!
var array = [1,2,4,15,99];
А для динамических объектов:
var dynObj = {fieldValue:10, fieldText:«test»};
Снять ограничения дженериков по части мат. операций.
Добавить Range'ы.
var array = [1,2,4,15,99];
А для динамических объектов:
var dynObj = {fieldValue:10, fieldText:«test»};
Снять ограничения дженериков по части мат. операций.
Добавить Range'ы.
1. var array = new[] {1,2,4,15,99};
3. Enumerable.Range(1, 10)
3. Enumerable.Range(1, 10)
1) Я маленько неточно выразился, не массив, а аррэй/вектор, т.е. чтобы в него добавлять/удалять можно было. Ну и new[] не очень радует… Правда C# от него, скорее всего, никуда не денется. Но спасибо за вариант.
3) if( a in Enumerable.Range(1,10) ) сработает?
3) if( a in Enumerable.Range(1,10) ) сработает?
1) Это можно уже в .Net 3.5
var list = new List {1,3,4,4,5,5,6};
var dict = new Dictionary { {1,2}, {2,3}};
var list = new List {1,3,4,4,5,5,6};
var dict = new Dictionary { {1,2}, {2,3}};
Вот от List и от Dictionary бы избавиться — об этом и речь. Ведь для чего это нужно? Чтобы по месту создавать данные объекты, не писать лишнего, и чтобы это читалось хорошо, сравните:
test.SendData( new List{1,3,5} );
test.SendData( [1,3,5] );
Второй вариант приятнее гораздо.
test.SendData( new List{1,3,5} );
test.SendData( [1,3,5] );
Второй вариант приятнее гораздо.
А мне это как раз не нравиться.
Если SendData будет иметь кучу перегрузок:
public void SendData(object o){...}
public void SendData(List list){...}
public void SendData(ArrayList list){...}
public void SendData(int[] array){...}
или что ещё хуже
public void SendData(T data){...}
то компилятору будет сложно понять какой из этих методов надо вызывать.
Если SendData будет иметь кучу перегрузок:
public void SendData(object o){...}
public void SendData(List list){...}
public void SendData(ArrayList list){...}
public void SendData(int[] array){...}
или что ещё хуже
public void SendData(T data){...}
то компилятору будет сложно понять какой из этих методов надо вызывать.
Парсер лох, съел мои генерики.
if (a.In(Enumerable.Range(1,10)) сработает
3) if( Enumerable.Range(1,10).Contains(a) ) сработает
2. Есть же анонимные типы
var person = new { Name=«Мальчик», Wish=«хочет», City=«Тамбов» };
var person = new { Name=«Мальчик», Wish=«хочет», City=«Тамбов» };
А этот объект можно потом куда-то передать именно как динамический и потом в другом уже классе или даже модуле обращаться к его полям?
Т.е. нечно такое:
otherObj.do( person );
Чтобы otherObj смог разобраться что там внутри? Ну и поля каждый раз разные можно передавать.
Т.е. нечно такое:
otherObj.do( person );
Чтобы otherObj смог разобраться что там внутри? Ну и поля каждый раз разные можно передавать.
Может Javascript устроит?
А это ветка не про C# случаем? Причем тут javascript?
Мне в шарпе не хватает тех плюшек, что есть в Actionscript.
Про проверку на null я уже молчу:
[AS3]: if( object ) ...;
[C#] if( object != null ) ...;
Этого даже просить бессмысленно — оно не укладывается в стандарт C#.
Мне в шарпе не хватает тех плюшек, что есть в Actionscript.
Про проверку на null я уже молчу:
[AS3]: if( object ) ...;
[C#] if( object != null ) ...;
Этого даже просить бессмысленно — оно не укладывается в стандарт C#.
>> [AS3]: if( object ) ...;
Нафиг такой говнокод.
А если уже так нужно перегрузите оператор неявного приведения к bool
Нафиг такой говнокод.
А если уже так нужно перегрузите оператор неявного приведения к bool
И что в нем плохого? Что меньше писать нужно?
Или он таит в себе опасность какую-то?
Вы не путайте опасность приведения типов и данный случай. Здесь ничего плохого произойти не может в принципе.
Или он таит в себе опасность какую-то?
Вы не путайте опасность приведения типов и данный случай. Здесь ничего плохого произойти не может в принципе.
От записи
if( object1 || object2 )
{… }
Вы будете вообще в шоке, но при этом здесь нет приведения типов!
if( object1 || object2 )
{… }
Вы будете вообще в шоке, но при этом здесь нет приведения типов!
Для таких целей служат другие языки ;) Хотя с dynamic поизвращаться можно, но я бы просто так писать не стал.
Реально не хватает группировки исплючений
> обрабатывать необходимые исключения в порядке важности, а все остальные — с помощью общего Exception.
Это некрасивый костыль, Pokemon Exception Handling
Это некрасивый костыль, Pokemon Exception Handling
Вижу примерно так:
sys_call:
int 0x80
ret
start:
push msg_len
push msg
push 1
sys_call:
int 0x80
ret
start:
push msg_len
push msg
push 1
Мне бы хотелось увеличения мощности стандартных .NET-классов, особенно, в плане математики.
Что мне очень понравилось в .NET 4.0 — это классы BigInteger и Complex. Но их можно было бы реализовать с более богатым функционалом (посмотреть хотя бы BigInteger из Java), а так же добавить много новых классов. Скажем класс BigDecimal (который, опять таки, в Java есть), класс для работы с матрицами произвольных размерностей и т.д.
Что мне очень понравилось в .NET 4.0 — это классы BigInteger и Complex. Но их можно было бы реализовать с более богатым функционалом (посмотреть хотя бы BigInteger из Java), а так же добавить много новых классов. Скажем класс BigDecimal (который, опять таки, в Java есть), класс для работы с матрицами произвольных размерностей и т.д.
попахивает оверхедом. Сделают еще один перл, будут потом девелоперы плеваться, передавая код друг-другу.
Динамика для C# — зло.
Динамика для C# — зло.
Я вижу его в гробу. А что?
я правильно понимаю, что статья — вольная фантазия автора на тему синтаксиса, не имеющая никакой обратной связи с объективной реальностью?
Больше всего меня расстраивает отсутствие возможности сделать атрибут вида
[Validator(v => v >= 10)]
int MyProp { get; set; }
ну или хотя бы просто генериков в атрибутах, или хотя бы адекватных параметров по умолчанию, так как те, что появились в C# 4.0 не работают с атрибутами.
А что вы имеете в виду под автофлагами? Назначение атрибута [Flags] всем enum'ам по умолчанию? Зачем?
[Validator(v => v >= 10)]
int MyProp { get; set; }
ну или хотя бы просто генериков в атрибутах, или хотя бы адекватных параметров по умолчанию, так как те, что появились в C# 4.0 не работают с атрибутами.
А что вы имеете в виду под автофлагами? Назначение атрибута [Flags] всем enum'ам по умолчанию? Зачем?
А Вы на Python случаем не писали? Практически половина синтаксических конструкций в нем используется.
Extension properties были бы очень кстати — ведь в F# сделали.
все кроме автоматических флагов у Enums есть в F#.
Я хотел бы увидеть вложенные методы (http://pfight.wincode.org/?p=38)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как вы видите .NET / C# 5.0?