Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата korvin @ 15.11.11, 08:07

зачем для каждого? если вам не на один раз, опишите класс

Это класс создания Integer. Мне что, для каждого типа, который я хочу использовать в качестве value словаря, такую фигню констрячить?

Цитата korvin @ 15.11.11, 08:07

почему же ущербным?

Ок. Реализуйте его - и обсудим.

Цитата korvin @ 15.11.11, 08:07

это делается один раз и навсегда

Только для одного типа value.

Цитата MyNameIsIgor @ 15.11.11, 08:12

Ок. Реализуйте его - и обсудим.

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

Цитата MyNameIsIgor @ 15.11.11, 08:12

Только для одного типа value.

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

Цитата korvin @ 15.11.11, 08:32

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

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

Цитата MyNameIsIgor @ 15.11.11, 08:51

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

зачем мне что-то улавливать? то, что вы с Qraizer'ом писали про шаблоны несколько страниц назад, мне понятно. я свою позицую по этому поводу достаточно точно описал. если Вы не можете озвучить эту "неуловимую суть", то я ничем помочь не могу.

Цитата korvin @ 14.11.11, 17:14

Цитата D_KEY @ 14.11.11, 13:36

Тут скорее показана работа интерфейсов, чем дженериков

да ну? не хватает ключевого слова "generic"? ну так можно NumC и FractionalC переименовать в GenericNum и GenericFractional соответственно

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

Добавлено 15.11.11, 14:05

Цитата korvin @ 15.11.11, 09:23

если Вы не можете озвучить эту "неуловимую суть", то я ничем помочь не могу.

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

Цитата DesweR @ 15.11.11, 04:42

Гмм... а вообще что спросить то хотел?

Ну как. Помнишь полемика была касательно разной семантики присваивания у ссылочных типов и не ссылочных?

Цитата D_KEY @ 15.11.11, 14:04

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

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

Добавлено 15.11.11, 15:41

Цитата D_KEY @ 15.11.11, 14:04

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

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

Цитата Qraizer @ 15.11.11, 15:32

Ну как. Помнишь полемика была касательно разной семантики присваивания у ссылочных типов и не ссылочных?

Семантика присваивания одинакова, а различаются способы хранения, но при чём тут:

Цитата Qraizer @ 15.11.11, 04:14

Гм. Эдак получается, что можно отсеять все классы, просто указав специализацией "производный от TObject"?

Типа хохма?

Цитата DesweR @ 16.11.11, 01:32

Семантика присваивания одинакова, а различаются способы хранения, ... Типа хохма?

Всё. Тема закрыта.

Цитата korvin @ 15.11.11, 15:40

с каких пор у нас интерфейсы научились быть параметризованными?

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

Цитата

и да, тайпклассы позволяют описывать реализацию метода, в отличие от

Ну см. на trait'ы в Scala.

Цитата

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

Лучше просто перечитай эту часть обсуждения.
Впрочем, как мне кажется, ты просто не понимаешь, что такое классы-политики(стратегии). А может даже все время в голове держишь тайпклассы, которые с генерацией типов не связаны.
Классы-политики - это нечто похожее на паттерн "Стратегия", только выполняемый во время компиляции и создающий некоторый тип с указанными особенностями(заданными через политики). И в такого рода задачах опциональные возможности необходимы, а недостатков попросту не имеют(ты так и не объяснил, какие видишь недостатки).

Добавлено 16.11.11, 06:58

Цитата DesweR @ 16.11.11, 01:32

Семантика присваивания одинакова

Она не может быть одинакова для "ссылочных типов" и "типов значений". И это верно для всех языков. Проблема в том, что в нормальных(с моей точки зрения) языках все типы или ссылочные, или нет. В противном же случае система типов распадается на две, что, как минимум, неприятно

Добавлено 16.11.11, 07:49
DesweR, подумай о разнице в семантике присваивания в ключе понятия идентичности. Объекты типа значения при присваивании останутся разными объектами, но будут иметь одинаковое значение. Объект ссылочных типов будет один и тот же для двух "ссылок" при присваивании.
В языке, где все типы ссылочные, никаких неоднозначностей не возникает - у нас всегда получается один объект(но мы можем явно запросить копию, если нужно).
В языке, где все типы нессылочные, тоже проблем нет - у нас всегда копируются значения, а для "ссылок" есть отдельный дженерик-тип - "указатель", "ссылка" и т.п., значением которого является ссылка на объект указанного типа. Кстати, тут у плюсовых ссылок тоже, ИМХО, не все гладко.
Когда же в языке присутствует и то, и другое, как в Delphi/Java/C#/etc., получается каша.
Лично я, как уже говорил, за то, чтобы все типы были ссылочными.

Сообщение отредактировано: D_KEY - 16.11.11, 08:35

Цитата D_KEY @ 16.11.11, 06:55

Тайпклассы же наоборот накладывают ограничения на объекты

эээ, нет не накладывают. какое ограничение накладывает, например, тайпкласс Show? впрочем отчасти ты прав, то, что делают дженерик-классы в яве, в хаскелле делается простыми параметризуемыми типами без тайпклассов.

korvin, относительно шаблонов. Попробую зайти с другой стороны.

Клиентом шаблона типа(особенно это касается как раз шаблонов с policy- и trait- параметрами), в первую очередь является тот, кто создает с помощью этого шаблона типы, а не тот, кто пользуется такими сгенерированными типами.
Возьмем пример попроще - строки в стандартной библиотеке.

template<class charT,                         // тип используемых символов
         class traits = char_traits<charT>,   // тип характеристик символов
         class Allocator = allocator<charT> > // аллокатор
class basic_string;

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

basic_string :: type -> type -> type -> type

В "реализации" все специализации - паттерны для pattern-matching'а, как и наличие обсуждаемых "опциональных" частей. А "обычная" реализация - это _

Сообщение отредактировано: D_KEY - 16.11.11, 09:28

Цитата D_KEY @ 16.11.11, 09:22

basic_string :: type -> type -> type -> type

В "реализации" все специализации - паттерны для pattern-matching'а, как и наличие обсуждаемых "опциональных" частей. А "обычная" реализация - это _

это совсем некорректное сравнение

Цитата korvin @ 16.11.11, 09:37

это совсем некорректное сравнение

Да весьма корректно. Особенно если учесть, что специализации и выбираются по сопоставлению с образцом...

Цитата korvin @ 16.11.11, 09:37

это совсем некорректное сравнение

Почему? Объясни разницу.