Здравствуйте, Astaroth, Вы писали:

A>Мне же теперь ночью будет критерий Коши с окровавленным топором сниться!..

скорее с красным молотком

Здравствуйте, MarW, Вы писали:
MW>Да, определение точно в стиле математиков... Кстати, а что имеется в виду под "подтипом"?
Вот то и имеется в виду, что если для каждого объекта о1 типа S существует объект о2 типа T такой, что для всех программ P, определённых в терминах T, поведение P останется неизменным при подстановке о1 вместо о2 , то S является подтипом T. Что непонятно-то?
MW>Если это "подкласс" (производный клас, дочерний класс), то определение не верно, ибо можно переопределить фукциональность подкласса так, что при замене им базового класса функциональность изменится, а класс всё равно останется подклассом...
Нет, определение не может быть неверным. С точки зрения этого определения твой унаследованный подкласс не является подтипом. И собственно за это сениор архитекторы бьют джуниор архитекторов логарифмической линейкой по кривым рукам.

Здравствуйте, AI, Вы писали:

AI>PS после прочтения этого принципа вспомнилась Ерёменко ( матанализ физтех)
AI>с теорией о чешуйчатой поверхности
AI>Так что имхо мат анализ для программиста нужен

Нет, просто автор матанализу переучился

Понять что-то из такого объяснения невозможно — нужно уже знать на момент прочтения

Здравствуйте, AI, Вы писали:

AI>

---

AI>Если для каждого объекта о1 типа S существует объект о2 типа T такой, что для всех программ P, определённых в терминах T, поведение P останется неизменным при подстановке о1 вместо о2 , то S является подтипом T .
AI>

---

Мляяя...
Мне же теперь ночью будет критерий Коши с окровавленным топором сниться!..

чера читая книжку Герб Саттер "Решение сложных задач на с++" столкнулся с таким определением принципа подстановкм LSP Барбары Лисков

---

Если для каждого объекта о1 типа S существует объект о2 типа T такой, что для всех программ P, определённых в терминах T, поведение P останется неизменным при подстановке о1 вместо о2 , то S является подтипом T .

---

PS после прочтения этого принципа вспомнилась Ерёменко ( матанализ физтех)
с теорией о чешуйчатой поверхности
Так что имхо мат анализ для программиста нужен

Здравствуйте, S.Yu.Gubanov, Вы писали:

К>>Надо бы ещё побить авторов терминологии, поскольку отношение наследования не есть отношение субкласс/суперкласс в теоретико-множественном понимании.

SYG>Например, в оберонах вместо термина "наследование" используется термин "расширение типа".

"Расширение типа" дословно означает переход к суперклассу (в ТМ-понимании).
В то же время наследование — более сложная штука.

Тип "указатель на наследника" является субклассом типа "указатель на базу".
Но является ли сам тип "наследник" субклассом или суперклассом базы — это уже вопрос.

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

Но чаще всего наследник не только расширяет функциональность, но и меняет контракт (где-то усиливая, а где-то ослабляя).

AI -> "Так что же такое программирование наука или ремесло? " :

A>

---

A> Если для каждого объекта о1 типа S существует объект о2 типа T такой,
A> что для всех программ P, определённых в терминах T, поведение P
A> останется неизменным при подстановке о1 вместо о2 , то S является
A> подтипом T .

A>

---

A> PS после прочтения этого принципа вспомнилась Ерёменко ( матанализ
A> физтех)
A> с теорией о чешуйчатой поверхности
A> Так что имхо мат анализ для программиста нужен

Все простое- сложно. Чтобы писать понятно и доходчиво — нужно прилагать
усилий больше.

Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...

Здравствуйте, AI, Вы писали:

AI>чера читая книжку Герб Саттер "Решение сложных задач на с++" столкнулся с таким определением принципа подстановкм LSP Барбары Лисков

[q]
AI>Если для каждого объекта о1 типа S существует объект о2 типа T такой, что для всех программ P, определённых в терминах T, поведение P останется неизменным при подстановке о1 вместо о2 , то S является подтипом T .
[q]
В такой формулировке Саттер выпячивает теоретико-множественные детали (сюръективность, классы эквивалентности), и прячет отличительную черту, а именно принцип проекции и предикат эквивалентности.

Здравствуйте, AI, Вы писали:

это способ зарабатывания денег

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, S.Yu.Gubanov, Вы писали:

К>>>Надо бы ещё побить авторов терминологии, поскольку отношение наследования не есть отношение субкласс/суперкласс в теоретико-множественном понимании.

SYG>>Например, в оберонах вместо термина "наследование" используется термин "расширение типа".

К>"Расширение типа" дословно означает переход к суперклассу (в ТМ-понимании).

А что такое "ТМ-понимание"?

В оберонах "расширение типа" означает то что буквально означает РАСШИРЕНИЕ типа. Что буквально обозначает слово "расширение"? Расширение — это когда был маленький, а стал большой, то есть расширился.

TYPE
  SpaceVector = EXTENSIBLE RECORD 
    X,Y,Z: REAL;
  END;
  
  SpaceTimeVector = RECORD (SpaceVector)
    T: REAL;
  END;

Тип SpaceVector был маленький и содержал только 3 переменных, а мы его взяли и расширили до типа SpaceTimeVector который стал больше (шире) чем SpaceVector на 1 переменную. Был маленький, а стал большой, что произошло? — правильно, произошло расширение!

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

К>>"Расширение типа" дословно означает переход к суперклассу (в ТМ-понимании).

SYG>А что такое "ТМ-понимание"?

Теоретико-множественное.

SYG>В оберонах "расширение типа" означает то что буквально означает РАСШИРЕНИЕ типа. Что буквально обозначает слово "расширение"? Расширение — это когда был маленький, а стал большой, то есть расширился.

А если я вместо наращивания, наоборот, усилил контракт?

class String
{
public:
  String(const char* s);
  ...
};

class StringUppercase : public String
{
public:
  StringUppercase(const char* s) : String(s)
  {
    assert(no_lowercase(s));
  }
  ...
};

По-моему, слово "наследование" вполне выражает суть явления. В отличие от "субклассирования" или "расширения", которые притягивают не вполне уместные аналогии из математики. Конечно, хоть горшком назови, но новичков это сбивает с толку, о чём уже говорил Синклер.

A> Если для каждого объекта о1 типа S существует объект о2 типа T
A> такой, что для всех программ P, определённых в терминах T,
A> поведение P останется неизменным при подстановке о1 вместо о2 , то
A> S является подтипом T .

Ну и что тут непонятного-то? Матанализ я, конечно, изучал. Но он тут
ИМХО не причем. Тут банальная логика.

Здравствуйте, Demon_TM, Вы писали:

A>> Если для каждого объекта о1 типа S существует объект о2 типа T
A>> такой, что для всех программ P, определённых в терминах T,
A>> поведение P останется неизменным при подстановке о1 вместо о2 , то
A>> S является подтипом T .

D_T>Ну и что тут непонятного-то? Матанализ я, конечно, изучал. Но он тут
D_T>ИМХО не причем. Тут банальная логика.

А я и не говорил что не понятно. я лишь хотел сказать о том что такой стиль изложения больно напоминает мат анализ и всё.

Здравствуйте, Demon_TM, Вы писали:

A>> Если для каждого объекта о1 типа S существует объект о2 типа T
A>> такой, что для всех программ P, определённых в терминах T,
A>> поведение P останется неизменным при подстановке о1 вместо о2 , то
A>> S является подтипом T .

D_T>Ну и что тут непонятного-то? Матанализ я, конечно, изучал. Но он тут
D_T>ИМХО не причем. Тут банальная логика.
а что такое не банальная логика?
типа матан — это не банальная логика.
))

Здравствуйте, Glen Able, Вы писали:

GA>Нет, просто автор матанализу переучился

GA>Понять что-то из такого объяснения невозможно — нужно уже знать на момент прочтения

понять то можно, но что это не очень читабельно — согласен. ИМХО, мозг чистую абстракцию плохо воспринимает, ему нужны образы.

Здравствуйте, AI, Вы писали:

Если для каждого объекта о1 типа S существует объект о2 типа T такой, что для всех программ P, определённых в терминах T, поведение P останется неизменным при подстановке о1 вместо о2 , то S является подтипом T .

Да, определение точно в стиле математиков... Кстати, а что имеется в виду под "подтипом"? Если это "подкласс" (производный клас, дочерний класс), то определение не верно, ибо можно переопределить фукциональность подкласса так, что при замене им базового класса функциональность изменится, а класс всё равно останется подклассом...

Здравствуйте, Sinclair, Вы писали:

S>Нет, определение не может быть неверным. С точки зрения этого определения твой унаследованный подкласс не является подтипом. И собственно за это сениор архитекторы бьют джуниор архитекторов логарифмической линейкой по кривым рукам.

Надо бы ещё побить авторов терминологии, поскольку отношение наследования не есть отношение субкласс/суперкласс в теоретико-множественном понимании.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Sinclair, Вы писали:

S>>Нет, определение не может быть неверным. С точки зрения этого определения твой унаследованный подкласс не является подтипом. И собственно за это сениор архитекторы бьют джуниор архитекторов логарифмической линейкой по кривым рукам.

К>Надо бы ещё побить авторов терминологии, поскольку отношение наследования не есть отношение субкласс/суперкласс в теоретико-множественном понимании.

Например, в оберонах вместо термина "наследование" используется термин "расширение типа".

Здравствуйте, Кодт, Вы писали:

К>А если я вместо наращивания, наоборот, усилил контракт?

Если Вы про контракты, то так нельзя. Есть интерфейс и есть реализация интерфейса. Больше ничего нет. Компонентно ориентированная парадигма такая. В оберонах нельзя изменить контракт. Так что, расширение типа — это в самом деле расширение...