Comments 31
Имхо, использовать анонимные типы в качестве ключей для мапы — это ни что иное как антипаттерн.
0
Поправьте «Анонимее типы»
0
public static T Cast<T>(this object obj, T type) {
return (T)obj;
}
object cat = new {
Name = «Барсик»,
Age = 1
};
var typedCat = cat.Cast(new {
Name = default(string),
Age = default(int)
});
Console.WriteLine(typedCat.Name);
+6
«частиных методов» замените на «частичных методов», а лучше «partial методов»
0
Не знаю для этого примера имхо мне больше нравится:
using System;
namespace ConsoleApplication4
{
class Program
{
public class Person
{
public string Name;
public string Surname;
}
static void Main(string[] args)
{
Console.WriteLine(GetFullName().Name);
Console.Read();
}
static Person GetFullName()
{
return new Person { Name = «Иван», Surname = «Иванов» };
}
}
}
using System;
namespace ConsoleApplication4
{
class Program
{
public class Person
{
public string Name;
public string Surname;
}
static void Main(string[] args)
{
Console.WriteLine(GetFullName().Name);
Console.Read();
}
static Person GetFullName()
{
return new Person { Name = «Иван», Surname = «Иванов» };
}
}
}
-2
Это как раз тот случай, которого хотелось бы избежать. К тому же, правилами хорошего тона, надо делать автопроперти, плюс ко всему,
var a = new Person {Name=«Иван», Surname=«Иванов»};
var b = new Person {Name=«Иван», Surname=«Иванов»};
a.GetHashCode() != b.GetHashCode();
a != b;
То есть, придется еще реализовывать две функции для работы с Dictionary.
var a = new Person {Name=«Иван», Surname=«Иванов»};
var b = new Person {Name=«Иван», Surname=«Иванов»};
a.GetHashCode() != b.GetHashCode();
a != b;
То есть, придется еще реализовывать две функции для работы с Dictionary.
+1
Кстати, если нужны Tuple можно сделать dll на F#
0
И может еще ента статейка пригодиться:
blogs.msdn.com/lucabol/archive/2008/04/08/a-c-library-to-write-functional-code-part-ii-tuples.aspx
blogs.msdn.com/lucabol/archive/2008/04/08/a-c-library-to-write-functional-code-part-ii-tuples.aspx
0
слышал что в C# 4.0 можно будет делать так:
public var GetCat() {
return new { Name = «Барсик», Age = 1 };
}
public var GetCat() {
return new { Name = «Барсик», Age = 1 };
}
0
ну это уже будет не строго типизированный язык.
ведь я могу написать так:
public var GetCat() {
if (this.IsEnabled)
return new { Name = «Барсик», Age = 1 };
else return 1;
}
ведь я могу написать так:
public var GetCat() {
if (this.IsEnabled)
return new { Name = «Барсик», Age = 1 };
else return 1;
}
+1
Тогда компилятор выдаст ошибку, мол не могу статически определить возвращаемый тип.
Ситуация аналогичная:
var items = new[] { «cat», «dog» }; // всё ок
var items = new[] { «cat», 4 }; // ошибка, компилятор не может определить тип переменной items
Ситуация аналогичная:
var items = new[] { «cat», «dog» }; // всё ок
var items = new[] { «cat», 4 }; // ошибка, компилятор не может определить тип переменной items
0
Почему то часто путают статическую и строгую типизацию. То, о чём Вы написали — это статическая типизация (тип переменной определяется на этапе компиляции).
Строгая типизация — это запрет на использование разных типов внутри одного выражения.
Строгая типизация — это запрет на использование разных типов внутри одного выражения.
0
Хы… C# все ближе и ближе к JavaScript.
-3
ничего подобного, ключевое слово «var» многих смущает, но ничего общего с javascriptoвым «var» оно не имеет. строгая типизация была, есть и будет.
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
0
Не, а ёлочки в коде — это жесть.
0
Вообще-то можно использовать рефлексию для чтения полей анонимных объектов. Вполне работает.
0
Типун вам на язык. Рефлексия должна быть последней инстанцией. Если решение проблемы подразумевает рефлексию — вы неправильно ее решаете. Имхо, рефлексия оправдана только для сериализации, любое другое ее использование — это ошибки проектирования и программирования (отельно следует оговрить, конечно Reflection Emit, однако, опять-таки, только для сериализации и, возможно, перформанса.)
0
Это вы с чего так вдруг решили?:) Я и Джимми Нильсен с Вами не согласны:).
0
Рефлексия — это медленно, это ран-тайм проверки, это запутанная архитектура. Любую задачу, которая решается через рефлекшн, можно решить без него. Рефлекшн — это как универсальная тригономтерическая подстановка, вроде и решает проблему, но через такие места…
0
И все равно не убедили. Ситуации бывают разные. Универсальных решений, к сожалению, нет. Всегда приходится искать компромисс. Совершенно очевидно, что решение через рефлексию будет более медленным, но если такое решение позволит мне убрать дублирование кода и при этом профайлер не покажет падение производительности, я выберу решение через рефлексию.
Вообще, разговор сильно смахивает на давние споры о GOTO!
Ответом может служить только контекст.
Вообще, разговор сильно смахивает на давние споры о GOTO!
Ответом может служить только контекст.
0
Насчет «любую» это вы погорячились, да и рантайм проверки это не всегда зло. Например в UI коде, когда метод исполняется всего несколько раз, отражение вполне годится (у меня был случай, я делал generic класс-валидатор и использовал отражение для вызова метода Parse для параметра-типа).
0
На мой взгляд, хеш с неопределённым типом ключа тоже претендует на ошибку проектирования. Причём ещё большой вопрос, что ошибочней. :)
0
идея хорошая, но я не буду её использовать на практике: сегодня одтельные значения «записи», используемой в качестве ключа не нужны, а завтра, глядишь и понадобятся.
0
Sign up to leave a comment.
Анонимные типы за пределами функции