Менее универсальные дженерики? Возможное решение для арифметики в универсальных шаблонах C #

Думаю, вы ищете функциональность языка функционального программирования в ООП. В таком случае используйте FP.

Например, в Scala вы можете заменить операторы, чтобы теперь можно было добавлять или умножать вашу матрицу.

Так обстоит дело с разными языками, но не со всеми языками ООП.

Почему дженерики должны иметь возможность складывать, если неочевидно, как складывать или умножать? Например, если у меня есть класс логарифмов, то умножение - это просто сложение чисел, но как компилятор мог это узнать?

В C # вы можете выполнить перегрузку оператора, которая должна решить проблему, на которую вы жалуетесь: http://msdn.microsoft.com/en-us/library/aa288467%28VS.71%29.aspx

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

Почему бы просто не разрешить Generic быть ограниченным списком типов?

Потому что тогда это не общий. Обобщения расширяют выразительность системы типов в целом; они не предназначены для использования в качестве дешевого механизма поиска и замены в духе шаблонов C ++.

Есть ли очевидные причины, по которым это невозможно реализовать?

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

Это невероятно глупо.

Что ж, когда я увижу Андерса в понедельник, я обязательно скажу ему, что Майк К. из Интернета считает его идеи глупыми.

Тот факт, что он даже предлагает это, показывает, насколько ограничены разработчики C #.

В самом деле, я хорошо осознаю свои личные ограничения. Мне еще многое предстоит узнать о разработке и реализации языков программирования.

Я также отмечаю, что мы также ограничены нашим бюджетом, рыночными силами, не зависящими от нас, а также многими другими факторами.

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

http://blogs.msdn.com/ericlippert/archive/2008/02/20/how-to-not-get-a-question-ansarded.aspx

Дженерики не являются шаблонами C ++. Компилятор будет разрешать операции только с параметрами универсального типа, которые он может проверить на соответствие этим параметрам, потому что точные типы, которые будут использоваться, не вставляются до JIT-компиляции. C ++ выполняет вставку во время компиляции и не заботится о том, можно ли показать, что операция действительна для каждого возможного значения T, если она действительна для конкретного значения T, которое вы фактически используете.

Кроме того, ограничение, подобное where T: int, не имеет смысла, потому что не может быть никаких типов, производных от int, поскольку int - это структура. Единственный тип, подчиняющийся этому ограничению, - это сам int. Если вы знаете, что ваш тип всегда будет int, дженерики станут спорными.

Я бы посоветовал (и прошу прощения за свои ограниченные знания, если это кому-то покажется запаздывающим) реализовать как шаблонную, так и общую функциональность с соответствующими ключевыми словами. После прочтения всего сообщения (да, всех) я должен сказать, что согласен с обоими взглядами: дженерики ни в коем случае не должны быть «дешевым механизмом поиска и замены в стиле шаблонов C ++», однако, когда вам нужно реализовать то же самое функция для 2+ типов становится чертовски надоедливой: P

Возможно, интерфейс IArithmetic, в котором указываются операторы, которые необходимо реализовать, можно использовать, чтобы немного ужесточить ограничения?

По той самой причине, которая была четко заявлена ​​в интервью, что добавление такого рода поддержки внесло бы существенные дополнительные сложности с очень незначительным дополнительным преимуществом. Если вы знаете, как разрабатывать и писать компиляторы, вы можете спорить (на каком-нибудь другом форуме), насколько это правда или ложь, но не о том, «глупо ли это» или насколько «ограниченными» могут быть разработчики, использующие этот язык. .