Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Имхо, использовать анонимные типы в качестве ключей для мапы — это ни что иное как антипаттерн.
Поправьте «Анонимее типы»
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);
«частиных методов» замените на «частичных методов», а лучше «partial методов»
Не знаю для этого примера имхо мне больше нравится:
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 = «Иванов» };
}
}
}
Это как раз тот случай, которого хотелось бы избежать. К тому же, правилами хорошего тона, надо делать автопроперти, плюс ко всему,
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.
Кстати, если нужны Tuple можно сделать dll на F#
И может еще ента статейка пригодиться:
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
слышал что в C# 4.0 можно будет делать так:
public var GetCat() {
return new { Name = «Барсик», Age = 1 };
}
public var GetCat() {
return new { Name = «Барсик», Age = 1 };
}
ну это уже будет не строго типизированный язык.
ведь я могу написать так:
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;
}
Тогда компилятор выдаст ошибку, мол не могу статически определить возвращаемый тип.
Ситуация аналогичная:
var items = new[] { «cat», «dog» }; // всё ок
var items = new[] { «cat», 4 }; // ошибка, компилятор не может определить тип переменной items
Ситуация аналогичная:
var items = new[] { «cat», «dog» }; // всё ок
var items = new[] { «cat», 4 }; // ошибка, компилятор не может определить тип переменной items
Почему то часто путают статическую и строгую типизацию. То, о чём Вы написали — это статическая типизация (тип переменной определяется на этапе компиляции).
Строгая типизация — это запрет на использование разных типов внутри одного выражения.
Строгая типизация — это запрет на использование разных типов внутри одного выражения.
Хы… C# все ближе и ближе к JavaScript.
ничего подобного, ключевое слово «var» многих смущает, но ничего общего с javascriptoвым «var» оно не имеет. строгая типизация была, есть и будет.
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)
Не, а ёлочки в коде — это жесть.
Вообще-то можно использовать рефлексию для чтения полей анонимных объектов. Вполне работает.
Типун вам на язык. Рефлексия должна быть последней инстанцией. Если решение проблемы подразумевает рефлексию — вы неправильно ее решаете. Имхо, рефлексия оправдана только для сериализации, любое другое ее использование — это ошибки проектирования и программирования (отельно следует оговрить, конечно Reflection Emit, однако, опять-таки, только для сериализации и, возможно, перформанса.)
Это вы с чего так вдруг решили?:) Я и Джимми Нильсен с Вами не согласны:).
Рефлексия — это медленно, это ран-тайм проверки, это запутанная архитектура. Любую задачу, которая решается через рефлекшн, можно решить без него. Рефлекшн — это как универсальная тригономтерическая подстановка, вроде и решает проблему, но через такие места…
И все равно не убедили. Ситуации бывают разные. Универсальных решений, к сожалению, нет. Всегда приходится искать компромисс. Совершенно очевидно, что решение через рефлексию будет более медленным, но если такое решение позволит мне убрать дублирование кода и при этом профайлер не покажет падение производительности, я выберу решение через рефлексию.
Вообще, разговор сильно смахивает на давние споры о GOTO!
Ответом может служить только контекст.
Вообще, разговор сильно смахивает на давние споры о GOTO!
Ответом может служить только контекст.
Насчет «любую» это вы погорячились, да и рантайм проверки это не всегда зло. Например в UI коде, когда метод исполняется всего несколько раз, отражение вполне годится (у меня был случай, я делал generic класс-валидатор и использовал отражение для вызова метода Parse для параметра-типа).
На мой взгляд, хеш с неопределённым типом ключа тоже претендует на ошибку проектирования. Причём ещё большой вопрос, что ошибочней. :)
идея хорошая, но я не буду её использовать на практике: сегодня одтельные значения «записи», используемой в качестве ключа не нужны, а завтра, глядишь и понадобятся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонимные типы за пределами функции