Динамическое ключевое слово C # 4 - почему бы и нет?

Question

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

Answer 1

Я думаю, что большая часть отвращения, которое люди выражают этой функции, сводится к тому, что «это плохая языковая функция, потому что она позволит плохим разработчикам писать плохой код». Если подумать, по этой логике все языковые возможности плохие.

Когда я сталкиваюсь с блоком VB-кода, которому какой-то гений поставил префикс On Error Resume Next, я проклинаю не VB. Может быть, я должен, я полагаю. Но по моему опыту, человек, который полон решимости положить пенни в блок предохранителей, найдет способ. Даже если вы опустошите его карманы, он вылепит свои собственные копейки.

Я, я с нетерпением жду более полезного способа взаимодействия между C # и Python. Я пишу все больше и больше кода, который делает это. Ключевое слово dynamic не может прийти достаточно скоро для этого конкретного случая использования, потому что нынешний способ сделать это заставляет меня чувствовать, что я советский академик в 1950-х, который едет на Запад для конференции: есть огромное количество правил и документов, прежде чем я уйду, я почти уверен, что кто-то будет наблюдать за мной все время, пока я там, и большая часть того, что я заберу, пока я там, будет забрана у меня на границе, когда Я возвращаюсь.

Answer 2

Некоторые видят в этом инструмент, которым будут злоупотреблять. Как "Option Strict Off" и "On Error Resume Next" в VB, которых никогда не было в "чистых" языках, таких как C # и Java.

Многие говорили то же самое о ключевом слове "var", но я не вижу, что оно злоупотребляло, как только стало понятно, что это не то же самое, что VB Variant

Это может быть использовано в местах, где ленивые разработчики не хотят проверять тип на классах и просто пытаются отлавливать динамические вызовы вместо того, чтобы писать "если бла-бла ...".

Лично я чувствую, что его можно правильно использовать в таких ситуациях, как этот недавний вопрос, на который я ответил.

Я думаю, что те, кто действительно понимает его мощь, сильно увлекаются динамическими языками .NET.

Answer 3

динамический плох, потому что такой код будет появляться повсюду:

public dynamic Foo(dynamic other) {
  dynamic clone = other.Clone();
  clone.AssignData(this.Data);
  return clone ;
}

вместо:

public T Foo<T>(T other) where T: ICloneable, IAssignData{
    T clone = (T)other.Clone();
    clone.AssignData(this.Data);
    return clone;
}

Первый, не имеющий статической информации о типе, не проверяющий время компиляции, не самодокументируемый, не определяющий тип, поэтому люди будут вынуждены использовать динамическую ссылку на сайте вызовов для сохранения результата, что приведет к большей потере типа и все это скручивается вниз.

Я уже начинаю бояться Динамика .

Редактировать : Опасность миновала (Фу!) ... и динамикой все же не злоупотребляли, нет необходимости опускать голосование за меня через 3 года:)

Answer 4

Настоящая ловушка? Сильное отсутствие документации. Вся архитектура приложения существует в сознании человека (или людей), который его написал. По крайней мере, при строгой типизации вы можете посмотреть, что делает объект, через определение класса. С динамической типизацией вы должны в лучшем случае вывести значение из его использования. В худшем случае у вас НЕТ ИДЕИ, что это за объект. Это как программирование всего на JavaScript. ACK!

Answer 5

Когда люди понимают, что IntelliSense с dynamic не получается, они переключаются с состояния dynamic на счастье dynamic, когда это необходимо и var на все другие раза.

Цели dynamic включают: взаимодействие с динамическими языками и платформами, такими как COM / C ++ и DLR / IronPython / IronRuby; а также превращение самого C # в IronSmalltalkWithBraces со всем, что реализует IDynamicObject.

Хорошие времена будут у всех. (Если вам не нужно поддерживать код, написанный кем-то другим.)

Answer 6

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

Нет причины, по которой вы не могли бы запретить использование "динамического" ключевого слова в своем собственном руководстве по кодированию, если оно вам не нужно. Так в чем проблема? Я имею в виду, если вы хотите сделать сумасшедшие вещи с ключевым словом «dynamic» и притвориться, что C # - некий двоюродный брат JavaScript, будьте моим гостем. Просто держи эти эксперименты подальше от моей кодовой базы. ;)

Answer 7

FUD. Это может быть лучше, чем нарезанный хлеб, но весь мой опыт работы с VB, JavaScript и т. Д. Дает мне ощущение, что C # будет динамически связываться. Я знаю, что смогу рационально рассмотреть его в ближайшем будущем и увидеть, насколько хороша эта новая функция для обеспечения взаимодействия с динамическими языками. Но это займет некоторое время. Я человек, хорошо? : -)

Answer 8

Я не вижу причины, по которой текущий способ динамического вызова методов имеет недостатки:

Это займет три строки, или вы можете добавить метод расширения в System.Object, чтобы сделать это за вас:

class Program
{
    static void Main(string[] args)
    {
        var foo = new Foo();            
        Console.WriteLine(foo.Invoke("Hello","Jonathan"));
    }        
}

static class DynamicDispatchHelper
{
    static public object Invoke(this object ot, string methodName, params object[] args)
    {
        var t = ot.GetType();
        var m = t.GetMethod(methodName);
        return m.Invoke(ot, args);
    }
}

class Foo
{
    public string Hello(string name)
    {
        return ("Hello World, " + name);
    }
}