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

Цитата Повстанець @ 27.01.11, 19:15

С каких это пор объектная модель делфи стала эталоном ООП, или хотя бы удачной его реализацией? Кто так сказал? С чего взял?

Ну, об этом хотя бы говорит факт очевидного сходства этой модели с моделями таких монстров как Java и C#. Думаю об удачности можно говорить, на эталон не претендую.

Цитата --Ins-- @ 27.01.11, 19:18

Ну, об этом хотя бы говорит факт очевидного сходства этой модели с моделями таких монстров как Java и C#.

И в каком месте они схожи? в блоке finaly ?

Цитата --Ins-- @ 27.01.11, 18:50

Цитата MyNameIsIgor @ 27.01.11, 18:45

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

Обычная декомпозиция конструктора. Я может там захочу флажок Constructing сбросить, в простейшем случае. Не заставлять же мне это делать вручную разработчика потомка?

Задача конструктора породить объект, следовательно конструктор не метод объекта(максимум - метод класса). В конструкторе базового класса ты не можешь знать, сконструирован ли объект производного класса, соответственно, не можешь знать, имеешь ли право вызывать виртуальный метод. Что не понятно? Сто раз обсуждалось со ссылкой на литературу по языкым, где разрешены полиморфные вызовы в конструкторе. У вас же понятие конструирования и полиморфной инициализации смешаны в одну кучу.

Цитата D_KEY @ 27.01.11, 19:17

Я не понимаю, зачем.

Угу. А как тогда поменять значение, если ты хочешь чтобы так было нельзя? В случае записи мы напишем:
Rect.Points[0] := Point(NewX, Rect.Points[0].Y);

а в случае класса как?

Цитата --Ins-- @ 27.01.11, 19:18

Ну, об этом хотя бы говорит факт очевидного сходства этой модели с моделями таких монстров как Java и C#.

Цитата KILLER @ 27.01.11, 19:19

И в каком месте они схожи?

Вот и подумай, ты же в Delphi у нас разбираешься

Цитата korvin @ 27.01.11, 19:08

Цитата D_KEY @ 27.01.11, 19:00

Все-таки там скорее нет мутабельных типов

есть =) ты Scheme in 48 hours читал? IORef например. другое дело, что все "мутации" ммм "инкапсулированы" в монаду IO, и втащив значение в монаду, назад его не вернешь. говорят есть еще всякие unsafe*-модули, позволяющие даже вытаскивать из монады чистое значение (вот это уже можно в некотором смысле назвать "оконстаниванием"), но про них я ничего не знаю и вообще, если начал их юзать, то стоит задуматься, зачем тебе вообще Хаскелл =)

Так я о том же, собственно. У меня пока очень сильно хромает терминология по таким языкам.

Цитата --Ins-- @ 27.01.11, 19:21

Вот и подумай, ты же в Delphi у нас разбираешься

Так в том то и дело, что подумал и не вижу каким местом они схожи, ну как пример разве что блок finaly есть в этих языках, это наверно единственно что их объекдиняет

Цитата korvin @ 27.01.11, 19:11

Цитата D_KEY @ 27.01.11, 19:04

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

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

Совершенно верно, и это еще одна причина говорить о том, что свойства не имеют смысла. Это какая-то нелепая попытка наложить дополнительные ограничения на поля...

Цитата --Ins-- @ 27.01.11, 19:20

Цитата D_KEY @ 27.01.11, 19:17

Я не понимаю, зачем.

Угу. А как тогда поменять значение, если ты хочешь чтобы так было нельзя? В случае записи мы напишем:
Rect.Points[0] := Point(NewX, Rect.Points[0].Y);

а в случае класса как?

Что мешает в случае класса сделать также?

Цитата Повстанець @ 27.01.11, 19:12

Нет, не должен. И TRect не должен. И integer не должен. И ещё целый парад типов также не должны это делать. Но тем не менее TRect является частью его состояния. И раз уж мне дали такой инструмент, как свойства которые собстно выставляют это поле напоказ, то должны дать инструмент позволяющий защитить моё поле от несанкционированного вмешательства. Вот в С++ этим инструментом является константность. А в делфи?

тебе дали инструмент -- инкапсуляция, скрой реализацию TRect (поле типа TPoint), возвращай свойство Left (значение Point.X) и Top (значение Point.Y)

хочешь возвращать точку? возвращай другой объект-точку с такими же координатами. иначе делай точки немутабельными

Сообщение отредактировано: korvin - 27.01.11, 19:25

Цитата korvin @ 27.01.11, 19:24

тебе дали инструмент -- инкапсуляция, скрой реализацию TRect, скрой его реализацию (TPoint), возвращай свойство Left (значение Point.X) и Top (значение Point.Y)

А вы уже не считаете, что свойства не к месту вообще?

Цитата --Ins-- @ 27.01.11, 19:13

Цитата D_KEY @ 27.01.11, 19:10

Доказательства, пожалуйста.

Да были уже. Ты как-то грозился повторить на уровне библиотеки объектную модель Delphi. До сих пор жду Реализуй мне NewInstance, Dispatch, AfterConstruction, BeforeDestruction, SafeCallException - ну, для начала хотя бы

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

Цитата Повстанець @ 27.01.11, 19:24

Что мешает в случае класса сделать также?

Как так же? Новый объект в куче создавать для того, чтобы изменить одно из ста свойств исходного? А че с ним потом делать? А с исходным че?

Цитата --Ins-- @ 27.01.11, 19:20

Цитата D_KEY @ 27.01.11, 19:17

Я не понимаю, зачем.

Угу. А как тогда поменять значение, если ты хочешь чтобы так было нельзя? В случае записи мы напишем:
Rect.Points[0] := Point(NewX, Rect.Points[0].Y);

а в случае класса как?

Так же.