История изменений
Исправление den73, (текущая версия) :
И тут мне два варианта видится: или дать гибкие примитивы из которых что угодно собрать можно или продумать базу, которую можно расширять не внося ломающих изменений.
Нет, это опасный путь - легко переборщить с гибкостью (пример: Перл).
В расте пошли по второму пути, время покажет насколько удачно эта самая база была выбрана. И это касается не только ООП.
Точно. Но мне как дизайнеру языка интересно опередить время, подсмотрев удачные идеи. Оказывается, в плане ООП раст не подходит, а сначала казалось, что отказ от наследования - это именно «фишка».
Конечно, язык не запрещает присвоить базовому классу наследника (так называемая «срезка»), но в итоге всё равно будет именно базовый класс, пусть и в потенциально несогласованном состоянии.
Ну, я не такой спец по плюсам, но я подозреваю, что виртуальный метод в этом случае будет вызван всё же от наследника. Чтобы стало иначе, компилятору нужно будет как-то особо извратиться. Там вроде есть (ты говорил, кажется) способ вызвать конкретный метод напрямую, но для этого уже пользователь должен предпринять особые телодвижения в каждой точке вызова. Из объявления типа, как я думаю, это не выводится. А могли бы сделать, что если тип = «точно Т», то и виртуальные методы вызываются только от этого типа, а не от потомков. С точки зрения объектной архитектуры это может быть и плохо, зато с т.з. производительности - самое то.
Исправление den73, :
И тут мне два варианта видится: или дать гибкие примитивы из которых что угодно собрать можно или продумать базу, которую можно расширять не внося ломающих изменений.
Нет, это опасный путь - легко переборщить с гибкостью (пример: Перл).
В расте пошли по второму пути, время покажет насколько удачно эта самая база была выбрана. И это касается не только ООП.
Точно. Но мне как дизайнеру языка интересно опередить время, подсмотрев удачные идеи. Оказывается, в плане ООП раст не подходит, а сначала казалось, что отказ от наследования - это именно «фишка».
Конечно, язык не запрещает присвоить базовому классу наследника (так называемая «срезка»), но в итоге всё равно будет именно базовый класс, пусть и в потенциально несогласованном состоянии.
Ну, я не такой спец по плюсам, но я подозреваю, что виртуальный метод в этом случае будет вызван всё же от наследника. Чтобы стало иначе, компилятору нужно будет как-то особо извратиться. Там вроде есть (ты говорил, кажется) способ вызвать конкретный метод напрямую, но для этого уже пользователь должен предпринять особые телодвижения в каждой точке вызова. Из объявления типа, как я думаю, это не выводится. А могли бы сделать, что если тип = «точно Т», то и виртуальные методы вызываются только от этого типа, а не от потомков.
Исходная версия den73, :
И тут мне два варианта видится: или дать гибкие примитивы из которых что угодно собрать можно или продумать базу, которую можно расширять не внося ломающих изменений.
Нет, это опасный путь - легко переборщить с гибкостью (пример: Перл).
В расте пошли по второму пути, время покажет насколько удачно эта самая база была выбрана. И это касается не только ООП.
Точно. Но мне как дизайнеру языка интересно опередить время, подсмотрев удачные идеи. Оказывается, в плане ООП раст не подходит, а сначала казалось, что отказ от наследования - это именно «фишка».
Конечно, язык не запрещает присвоить базовому классу наследника (так называемая «срезка»), но в итоге всё равно будет именно базовый класс, пусть и в потенциально несогласованном состоянии.
Ну, я не такой спец по плюсам, но я подозреваю, что виртуальный метод в этом случае будет вызван всё же от наследника. Чтобы стало иначе, компилятору нужно будет как-то особо извратиться.