Анонимные типы за пределами функции

[lam0x86]

Имхо, использовать анонимные типы в качестве ключей для мапы — это ни что иное как антипаттерн.

[Sane]

Хм. Да, возможно, вы правы. Но, думаю, анонимные типы в качестве ключей hash-based коллекций вполне имеют право на существование. Например, чтобы посчитать количество Tuple'ов — заполнять ими HashSet.

[XaocCPS]

Поправьте «Анонимее типы»

[Sane]

Спасибо, поправил.

[SHSE]

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);

[Sane]

Да, но опять-таки вы описываете тип внутри вашей новой функции. Да и extension method для object как-то чересчур.

[zabr]

«частиных методов» замените на «частичных методов», а лучше «partial методов»

[Sane]

Поправил, спасибо. Хотелось бы все-таки избегать мешанины русского и английского, и так на работе уши вянут от «Засабмитай баг на Кью-Эй», «Заэстимировал реквайрмент — эффорт ларджь».

[zabr]

Не знаю для этого примера имхо мне больше нравится:

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 = «Иванов» };
}

}
}

[Sane]

Это как раз тот случай, которого хотелось бы избежать. К тому же, правилами хорошего тона, надо делать автопроперти, плюс ко всему,

var a = new Person {Name=«Иван», Surname=«Иванов»};
var b = new Person {Name=«Иван», Surname=«Иванов»};

a.GetHashCode() != b.GetHashCode();
a != b;

То есть, придется еще реализовывать две функции для работы с Dictionary.

[zabr]

Вы правы, признаю свою ошибку, не о том думал…

[zabr]

Кстати, если нужны Tuple можно сделать dll на F#

[zabr]

И может еще ента статейка пригодиться:

blogs.msdn.com/lucabol/archive/2008/04/08/a-c-library-to-write-functional-code-part-ii-tuples.aspx

[SHSE]

слышал что в C# 4.0 можно будет делать так:

public var GetCat() {
return new { Name = «Барсик», Age = 1 };
}

[dtest]

ну это уже будет не строго типизированный язык.

ведь я могу написать так:

public var GetCat() {

if (this.IsEnabled)
return new { Name = «Барсик», Age = 1 };
else return 1;
}

[SHSE]

Тогда компилятор выдаст ошибку, мол не могу статически определить возвращаемый тип.

Ситуация аналогичная:

var items = new[] { «cat», «dog» }; // всё ок

var items = new[] { «cat», 4 }; // ошибка, компилятор не может определить тип переменной items

[markshevchenko]

Почему то часто путают статическую и строгую типизацию. То, о чём Вы написали — это статическая типизация (тип переменной определяется на этапе компиляции).

Строгая типизация — это запрет на использование разных типов внутри одного выражения.

[mx2000]

Хы… C# все ближе и ближе к JavaScript.

[AndreyTS]

ничего подобного, ключевое слово «var» многих смущает, но ничего общего с javascriptoвым «var» оно не имеет. строгая типизация была, есть и будет.
посмотрите проект Nemerle (http://www.rsdn.ru/article/nemerle/NemerleIntro.xml) — на этом языке и не такие фрагменты кода можно увидеть, внешне выглядящие как динамически типизированные, но при этом он остаётся строго статически типизированным языком. Вывод типов — наше всё:)

[malicious]

Не, а ёлочки в коде — это жесть.

[zabr]

+5

[Sane]

Это парсер хабра так код портит.

[malicious]

Да, а то вот я не понял.

[ofigenn]

Вообще-то можно использовать рефлексию для чтения полей анонимных объектов. Вполне работает.

[Sane]

Типун вам на язык. Рефлексия должна быть последней инстанцией. Если решение проблемы подразумевает рефлексию — вы неправильно ее решаете. Имхо, рефлексия оправдана только для сериализации, любое другое ее использование — это ошибки проектирования и программирования (отельно следует оговрить, конечно Reflection Emit, однако, опять-таки, только для сериализации и, возможно, перформанса.)

[ofigenn]

Это вы с чего так вдруг решили?:) Я и Джимми Нильсен с Вами не согласны:).

[Sane]

Рефлексия — это медленно, это ран-тайм проверки, это запутанная архитектура. Любую задачу, которая решается через рефлекшн, можно решить без него. Рефлекшн — это как универсальная тригономтерическая подстановка, вроде и решает проблему, но через такие места…

[ofigenn]

И все равно не убедили. Ситуации бывают разные. Универсальных решений, к сожалению, нет. Всегда приходится искать компромисс. Совершенно очевидно, что решение через рефлексию будет более медленным, но если такое решение позволит мне убрать дублирование кода и при этом профайлер не покажет падение производительности, я выберу решение через рефлексию.
Вообще, разговор сильно смахивает на давние споры о GOTO!
Ответом может служить только контекст.

[self]

Насчет «любую» это вы погорячились, да и рантайм проверки это не всегда зло. Например в UI коде, когда метод исполняется всего несколько раз, отражение вполне годится (у меня был случай, я делал generic класс-валидатор и использовал отражение для вызова метода Parse для параметра-типа).

[markshevchenko]

На мой взгляд, хеш с неопределённым типом ключа тоже претендует на ошибку проектирования. Причём ещё большой вопрос, что ошибочней. :)

[RollingStone]

идея хорошая, но я не буду её использовать на практике: сегодня одтельные значения «записи», используемой в качестве ключа не нужны, а завтра, глядишь и понадобятся.