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

Цитата DesweR @ 04.05.11, 04:00

Это не развитие - это заблуждение, но речь не об этом...

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

Цитата DesweR @ 04.05.11, 04:00

Цитата Qraizer @ 30.04.11, 16:10

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

И что ты понял из наших слов?
О "монолитности"?
О "неявлении себя базовым классом при наследовании"?
О "о полном контроле базовых классов производным"?
О "вмешательстве базовых классов в дела производных"?

Попробуй лучше объяснить поведение ваших конструкторов в базовых и производных классах, с точки зрения инвариантов класса и его дополнении при наследовании. Думаю, ты понимаешь, что инвариант производного класса является конъюнкцией инвариантов всех базовых классов и собственного инварианта. А также мне интересно, кто и как способен гарантировать инвариант только что созданного объекта, кроме конструктора соответствующего класса(даже если он базовый) и о какой поддержке инварианта может идти речь при вызове полиморфного метода при конструировании?
Меня настораживает не столько наличие в языке полиморфных с точки зрения объектов конструкторов(так это "работает" во многих языках), сколько активное использование этого механизма и выгораживания его в качестве преимущества. Хотя в других языках его применять не рекомендуют, хотя и возможность есть.

Цитата

Цитата D_KEY @ 01.05.11, 15:10

Нет. С "высоты полета" более развитое ООП у ruby, python, scala, etc.

Но речь то совсем не о них

Значит речь и не о "высоте полета". У Delphi нет более развитого ООП, есть более сложное, а это совсем ни одно и тоже

Цитата

Цитата D_KEY @ 01.05.11, 20:51

Цитата korvin @ 01.05.11, 20:50

Цитата D_KEY @ 01.05.11, 20:45

Зачем получать список методов в рантайме?

чтобы узнать, на какие сообшения может ответить неизвестный объект. // K.O.

Зачем работать с неизвестным объектом?

А зачем тогда вообще работать с динамическими объектами?

"динамические" - это какие? Речь идет о языке со статической типизацией, и если мы не хотим, чтобы ОО-часть языка являлась отдельной пристройкой к языку, то и класс объекта, который нам нужен, должен быть указан, а код должен уметь работать с объектами указанного и производных классов. Можешь курить все того же Мейера.
То, что мы можем делать с объектом, определяется статически, то, как он это делает - динамически.

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

Цитата KILLER @ 02.05.11, 21:45

ты ведь сам предложил извратный метод, взять потроха объекта неизвестного типа и кинуть по сети...

вовсе нет, вместо объекта кидаем ссылку

Добавлено 04.05.11, 09:17

Цитата D_KEY @ 02.05.11, 20:50

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

почему магическим? достаточно определить пару стандартных операций: получение интерфейса и посылка сообщения.

Добавлено 04.05.11, 09:26

Цитата D_KEY @ 03.05.11, 10:13

Реализация в Delphi интересна, но дело не в интерфейсах/абстрактных классах, о в свойствах и делегировании им части реализации класса

а я вообще не понял, что он хотел этим показать =/
Romkin, ты хоть вывод программы покажи =)

Цитата korvin @ 04.05.11, 09:14

достаточно определить пару стандартных операций: получение интерфейса

А метод, отдающий этот интерфейс, точно лежит там, где ты его искать будешь?

Цитата korvin @ 04.05.11, 09:14

Цитата D_KEY @ 02.05.11, 20:50

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

почему магическим? достаточно определить пару стандартных операций: получение интерфейса и посылка сообщения.

Осталось понять, зачем? Велосипедишь все?
А с точки зрения языков... В языке со статической типизацией(да, я считаю, что она лучше), это делать не имеет смысла, в языке с динамической... Ну не знаю, утиная типизация вполне справляется.

Добавлено 04.05.11, 09:32

Цитата korvin @ 04.05.11, 09:14

Цитата D_KEY @ 03.05.11, 10:13

Реализация в Delphi интересна, но дело не в интерфейсах/абстрактных классах, о в свойствах и делегировании им части реализации класса

а я вообще не понял, что он хотел этим показать =/
Romkin, ты хоть вывод программы покажи =)

Свойствам делигируется реализация интерфейсов.

Цитата trainer @ 04.05.11, 09:26

А метод, отдающий этот интерфейс, точно лежит там, где ты его искать будешь?

что значит "метод лежит там"?

Ну ты же собираешься некий шумоподобный набор байтов передавать - "неизвестные объекты".

Цитата korvin @ 04.05.11, 09:14

вовсе нет, вместо объекта кидаем ссылку

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

Цитата korvin @ 04.05.11, 09:14

Цитата (D_KEY @ Вчера, 14:13)
Реализация в Delphi интересна, но дело не в интерфейсах/абстрактных классах, о в свойствах и делегировании им части реализации класса

а я вообще не понял, что он хотел этим показать =/
Romkin, ты хоть вывод программы покажи =)

А что там показывать? Полный набор всех сочетаний вида "Hello from Foo A and Hello from Bar M", ну и соответственно для A-N, A-O, B-M и т.д. Просто динамическая сборка потомка двух классов, скажем так.

Цитата D_KEY @ 04.05.11, 09:31

Свойствам делигируется реализация интерфейсов.

НЕ свойствам. Самому объекту, однако. К свойствам обращения вообще нет.

Цитата D_KEY @ 04.05.11, 09:31

А с точки зрения языков... В языке со статической типизацией(да, я считаю, что она лучше), это делать не имеет смысла, в языке с динамической... Ну не знаю, утиная типизация вполне справляется.

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

а утиная типизация возможно так и работает.

D_KEY, ты похоже так и не понял. Вот дается тебе dll, в котрой метод получения IFoo и IBar, в твоей терминологии - абстрактных классов. Твоя задача - в своем приложении создать объект, реализующий одновременно IFoo и IBar, подгружая dll динамически (она может меняться). То есть, динамическое наследование от двух предков. На Delphi эта задача решается элементарно, просто вместо явного создания классов ставится получение интерфейсов.

Цитата Romkin @ 04.05.11, 09:39

Цитата D_KEY @ 04.05.11, 09:31

Свойствам делигируется реализация интерфейсов.

НЕ свойствам. Самому объекту, однако. К свойствам обращения вообще нет.

Значит, я не так понял. Мне казалось, что вот тут объект делегирует реализацию интерфейса своему свойству:

property Foo: TFoo read FFoo implements IFoo;

Т.е. говорим, что реализовывать интерфейс IFoo будет не сам объект нашего класса, а Foo.
Нет? А что тогда это значит?

Добавлено 04.05.11, 10:00

Цитата korvin @ 04.05.11, 09:42

Цитата D_KEY @ 04.05.11, 09:31

А с точки зрения языков... В языке со статической типизацией(да, я считаю, что она лучше), это делать не имеет смысла, в языке с динамической... Ну не знаю, утиная типизация вполне справляется.

ээ.. вот есть у тебя скомпилированная программа, возвращающая как результат работы какие-то объекты, как ты с ними собрался работать?

"Какие-то объекты" - это как? Просто поток бинарных данных ?

Цитата

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

А как еще ты собрался с ними работать? Откуда брать о них информацию? В любом случае должно быть нечто, что будет уметь понимать тип объекта. Как иначе-то?

Цитата D_KEY @ 04.05.11, 09:51

"Какие-то объекты" - это как?

это объекты, описания классов и интерфейсов которых тебе не доступны на этапе компиляции

Добавлено 04.05.11, 10:25

Цитата D_KEY @ 04.05.11, 09:51

А как еще ты собрался с ними работать? Откуда брать о них информацию? В любом случае должно быть нечто, что будет уметь понимать тип объекта. Как иначе-то?

у них и спрашивать

Цитата D_KEY @ 04.05.11, 09:51

Т.е. говорим, что реализовывать интерфейс IFoo будет не сам объект нашего класса, а Foo.
Нет? А что тогда это значит?

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

Ромкин, я всё-таки не совсем понимаю, какие тут преимущества перед простой композицией объектов