> But not every IsA relationship should be subclassing
OK. Можете привести содержательный подтверждающий пример? (вопросы эффективности побоку, интересен именно случай, когда IsA принципиально нельзя превращать в наследование)
> The semantics for String#substring clearly demand that the returned object should have the same class as the original.
Это не факт. К примеру, если мы рассматриваем в качестве производного класса X строки, означающие имена людей, то отнюдь не всякая подстрока имени человека будет также являться именем человека. :-)
Аргументы в пользу generic programming сами по себе достаточно ясны. Не ясно другое - каким образом они доказывают неполноту ОО? - "issues of function domain can't be handled by OO alone". В данном примере со строками мы попросту выигрываем в объеме "ручного" кодирования. Тот же выигрыш можно было бы получить, если бы ОО-язык поддерживал "сужение" типов при использовании имплементаций в производном классе.
> Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit,
Почему же "explicit"? Коль уж мы говорим о базовых и производных классах, речь как раз о неявных преобразованиях.
> and it really helps readability when you come back to the code some months later.
А какие же проблемы могут возникнуть с пониманием кода, где действительное число используется в качестве комплексного???
> Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Вы попросту исходите из общепринятого взгляда на наследование, который я и критикую в этом топике. Этот взгляд, в частности, предполагает, что в момент описания производного класса, все его базовые классы и интерфейсы доступны и известны (перечислены в списке наследования производного класса). Стоит лишь отказаться от этого взгляда, позволить, например, чтобы связь между базовым классом комплексных чисел и производным классом действительных чисел была введена при описании класса комплексных чисел, как ваша демонстрация "абсурда" становится нерелевантной.
> They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
И это тоже нерелевантно, в силу того же самого.
> This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading.
Неявное преобразование плавающих чисел в целые, конечно же, непозволительно. Что до обратного преобразования, то никаких проблем оно, на мой взгляд, не несёт (правда, при условии, что плавающее число имеет достаточно разрядов для точного представления всех разрядов целого числа).
> I think this explains my point about IsA relationships and subclassing.
Да, это проясняет ваш взгляд, но не делает основательность ваших взглядов доказанной. В частности, если возможна потеря точности при переходе от целого типа к плавающему, то отношение IsA попросту нельзя считать вполне наличествующим.
> Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2004-06-05 07:21 am (UTC)OK. Можете привести содержательный подтверждающий пример? (вопросы эффективности побоку, интересен именно случай, когда IsA принципиально нельзя превращать в наследование)
> The semantics for String#substring clearly demand that the returned object should have the same class as the original.
Это не факт. К примеру, если мы рассматриваем в качестве производного класса X строки, означающие имена людей, то отнюдь не всякая подстрока имени человека будет также являться именем человека. :-)
Аргументы в пользу generic programming сами по себе достаточно ясны. Не ясно другое - каким образом они доказывают неполноту ОО? - "issues of function domain can't be handled by OO alone". В данном примере со строками мы попросту выигрываем в объеме "ручного" кодирования. Тот же выигрыш можно было бы получить, если бы ОО-язык поддерживал "сужение" типов при использовании имплементаций в производном классе.
> Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit,
Почему же "explicit"? Коль уж мы говорим о базовых и производных классах, речь как раз о неявных преобразованиях.
> and it really helps readability when you come back to the code some months later.
А какие же проблемы могут возникнуть с пониманием кода, где действительное число используется в качестве комплексного???
> Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Вы попросту исходите из общепринятого взгляда на наследование, который я и критикую в этом топике. Этот взгляд, в частности, предполагает, что в момент описания производного класса, все его базовые классы и интерфейсы доступны и известны (перечислены в списке наследования производного класса). Стоит лишь отказаться от этого взгляда, позволить, например, чтобы связь между базовым классом комплексных чисел и производным классом действительных чисел была введена при описании класса комплексных чисел, как ваша демонстрация "абсурда" становится нерелевантной.
> They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
И это тоже нерелевантно, в силу того же самого.
> This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading.
Неявное преобразование плавающих чисел в целые, конечно же, непозволительно. Что до обратного преобразования, то никаких проблем оно, на мой взгляд, не несёт (правда, при условии, что плавающее число имеет достаточно разрядов для точного представления всех разрядов целого числа).
> I think this explains my point about IsA relationships and subclassing.
Да, это проясняет ваш взгляд, но не делает основательность ваших взглядов доказанной. В частности, если возможна потеря точности при переходе от целого типа к плавающему, то отношение IsA попросту нельзя считать вполне наличествующим.
> Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise.
Какая ж практика без теории? :-)