Ваши комментарии

← →
Mike B. © (2003-06-10 17:27) [0]

по поводу вот этого
http://voblin.nm.ru/objects_classes.dhtml

← →
Юрий Федоров © (2003-06-10 17:41) [1]

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

← →
nikkie © (2003-06-10 17:53) [2]

с комбинаторикой у автора не очень... я так и не понял, что он посчитал формулой V(x) = x^3/6 - x/6. причем здесь число сочетаний из (x+1) по 3? всего есть (2^x - x - 1) способов выбрать более 1 предмета из x разных предметов.

← →
nikkie © (2003-06-10 18:21) [3]

допер... С_{x+1}^3 = С_x^3 + C_x^2, треугольник Паскаля, блин... но вроде в тексте нет упоминаний, что комбинировать можно не более 3 классов...

← →
Sandman25 © (2003-06-11 10:25) [4]

А мне понравилась идея, что классификация строится на основе конкретного объекта, а не всего класса. Действительно, один объект класса А может являться одновременно и объектом класса Б, и объектом класса В, а другой объект класса А может и не являться ни Б, ни В, но зато является объектом класса Г. Есть в этом что-то более приближенное к реальности, чем в традиционном ООП. Правда, с вызовом виртуальных функций (методов) у автора проблема - нельзя однозначно определить, в каком порядке их вызывать.

← →
Andrey007 (2003-06-11 10:48) [5]

А чем предлагаемый подход отличается от множественного наследования? Я не заметил никакой разницы.

← →
fool © (2003-06-11 10:54) [6]

Идея понравилась, хотя и сыровата на мой взгляд.

← →
uw © (2003-06-11 11:44) [7]

>Юрий Федоров © (10.06.03 17:41)
><Andrey007 (11.06.03 10:48)

И нтерфейсы, и множественное наследование предполагают реализацию на этапе создания класса. Объект данного класса будет обладать функциональностью класса и не более. Он, как я понял, хочет однажды создать объект (экземпляр) и динамически наделять его функциональностью разных классов в зависимости от того, где объект оказался - в аптеке или в автобусе. Флаг в руки!

← →
Andrey007 (2003-06-11 12:23) [8]

>uw © (11.06.03 11:44)

IMHO, это непринципиальное отличие от множественного наследования - просто небольшое удобство, и не более того. А если говорить с точки зрения идеологии программирования, теории, так сказать, то всё то же самое.

<quote>
Мы тоже создадим класс clPersistent, имеющий методы Read() и Save() и классы clClient и clOrder, таких методов не имеющие. Запись реквизитов контрагента в базу данных будет производиться в процедуре Save() виртуального класса (clPersistent, clClient), реквизитов заказа - в процедуре, реализованной для (clPersistent, clOrder).
</quote>

Опупеть.
Пусть есть класс Persistent описанный, скажем, где-нибудь в Voblin.System.Streaming.
Теперь я пишу новый модуль Shark.Izvraty и в нём новый класс, какой-нибудь SuperPuperYoMoe.
Следуя принципу синергизма классов после связывания пакетов Voblin.System.Streaming и Shark.Izvraty должен образоваться виртуальный класс (SuperPuperYoMoe, Persistent), который будет уметь сохраняться в потоки.

Во блин...

Шо-то я не понял, зачем смешивать в одну кучу наследование и роли... Кроме путаницы ничего не получится. IMHO

Ваши комментарии Найти похожие ветки