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

S>Да, можно. Аргументируется это тем, что на самом деле это не конструкторы/деструкторы в смысле С++. У них другая семантика. Та работа, которая возлагается на конструктор класса в С++, выполняется статическим методом TObject.InitInstance. А то, что называется конструктором в Delphi, идеологически ближе к виртуальным инициализаторам. С деструктором класса ситуация аналогичная — поскольку это финализатор, вызов предка является делом вкуса.

Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов? Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?

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

В>Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов?
Потому, что "нормальные" деструкторы/конструкторы нельзя сделать виртуальными. Для упрощения компонентной модели в язык принудительно ввели автоматическую реализацию паттерна "абстрактная фабрика", которая и потребовала таких решений. Да, упрощение языка имеет свою цену — например, автоматических объектов в Delphi нет. Как, впрочем, и в Pascal
В>Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?
Нет никакой кривизны в таком решении. Нельзя смотреть на мир через призму объектной модели единственного языка. С точки зрения ООП, конструктор вообще не является необходимым элементом — вполне можно обходиться и без него.

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

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

В>>Хорошо. Это не конструкторы и не деструкторы, а инициализаторы и финализаторы. А какой в них смысл в таком виде и почему разработчики языка сделали выбор в их пользу, а не в пользу "нормальных" деструкторов/конструкторов?
S>Потому, что "нормальные" деструкторы/конструкторы нельзя сделать виртуальными.

Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые. Было бы желание. Не говоря о том, что можно было просто заплатку на компилятор налепить — требовать (от программиста) обязательного вызова конструкторов/деструкторов базовых классов (как в джаве). И "наглядность" никуда не денется и вероятность глюков меньше.

S>Для упрощения компонентной модели в язык принудительно ввели автоматическую реализацию паттерна "абстрактная фабрика", которая и потребовала таких решений.

Не требует она таких решений. Она требует лишь полной инициализации VMT до вызова конструктора базового класса.

S>Да, упрощение языка имеет свою цену — например, автоматических объектов в Delphi нет. Как, впрочем, и в Pascal

Принципиального упрощения я тоже здесь не вижу. Делов-то — вставить по умолчанию вызов конструктора/деструктора базового класса.

В>>Не верится, что в пору зарождения object pascal ООП было в настолько зачаточном состоянии, что разработчики не увидели кривизны такого решения?
S>Нет никакой кривизны в таком решении. Нельзя смотреть на мир через призму объектной модели единственного языка. С точки зрения ООП, конструктор вообще не является необходимым элементом — вполне можно обходиться и без него.

Можно. Зачем тогда сделали "подобие"?

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

В>Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые.

Цена этому совмещению — то, что в билдере несозиожно (насколько мне известно — пусть меня поправят, если я ошибаюсь),
напрямую работать с дельфийскими метаклассами.
Приходится отдавать их, как чёрный ящик, функциям, написанным на паскале (напр TApplication.CreateForm),
которые выполняют работу, которую выполнить на Сях нельзя как раз из-за
концепции их конструкторов.

Как, например, в билдере записать такую простейшую дельфийскую ф-ю?

function CreateComp(AClass: TComponentClass; AOwner: TComponent): TComponent; 
begin
  Result := AClass.Create(AOwner);
  // Это краеугольный камень визуальности и сериализации Дельфей
end;

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

В>>Я уже говорил, что не вижу проблем в таком совмещении. Пример — тот же билдер. Там конструкторы и деструкторы VCL-объектов ведут себя почти так же как плюсовые.
А>Цена этому совмещению — то, что в билдере несозиожно (насколько мне известно — пусть меня поправят, если я ошибаюсь), напрямую работать с дельфийскими метаклассами.

Нет. Невозможность в том, что борланд не удосужился сделать синтаксис
для ручного вызова конструктора в билдере. Паскальные "заглушки" нужны только для того, чтобы вызывать этот пресловутый Create, который "мапится" на плюсовый конструктор соответствующего класса. Можно обойтись и без паскаля, если напрямую залезть в VMT (пример где-то пробегал).

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

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

В>>>Аппетит приходит во время еды В дельфе их нет, поэтому и необходимости в них не испытываешь (если не писал то этого на более других языках).
S>> Бог с ним. Только в Net и Яве они не использутся.

В>Я ж говорю — там есть альтернатива в виде GC (со своими рулезами и недостатками), у дельфи никакой альтернативы нет. Исключительно ручки программиста. И не надо песен про наглядность и удобство дельфи. Наглядность и удобство кончается в обжект инспекторе. Код — громоздкий и неудобный.

Да меня на данном этапе Native Delphi вообще не волнует так же как и Борланда.
В>[...]
В>>>Дык, в чем простота-то? В необходимости делать Free и городить лестницы из try/finally? Спасибо конечно, но мне как-то проще объявить объект и использовать его, а не заботиться о его уничтожении и последствиях бросания исключений. А в качестве бонуса — еще и минимальные затраты на распределение памяти.

S>> Либо за тебя это делает компилятор

В>Да, за меня это делает компилятор. За что ему большое спасибо. И Страуструпу тоже А как следствие — от компилятора не требуется специальная поддержка строк, интерфейсов и прочих динамических массивов. Все делается средствами языка. Вот это я и называю гибкостью языка, а не произвольный порядок вызова конструкторов/деструкторв
Это гибкость не языка а компилятора.

В>[...]
В>>>Ну так и говори о иерархии и компонентности. Язык совершенно другой, причем лишенный таких ярко выраженных огрехов как в настоящей дельфе.
S>> Язык как раз тот же. Кстати на данном этапе совместим на 90%. Но хотелось бы большего.

В>Хотелось бы ручками делать Free? Так что там, кстати, с порядком вызова деструкторов? А они там вообще есть? На 90% совместим, говоришь?
А Free тебе по любому вызывать придется для освобождения системных ресурсов.
С вызовами деструкторов все так же как и в Delphi.

В>[...]
В>зачем вызывать деструктор этого класса до наследника?
S>> Устал объяснять. Может сам столкнешься.

В>Сомневаюсь Теорию осмысленности такого поведения ты мне не смог объяснить, пример привести тоже. Очевидно потому, что все примеры, когда ты использовал эту "особенность" не выдерживают критики с точки зрения дизайна.
Иногда дизайн на все случаи жизни не предусмотреть, а взять некий класс и с минимальными потребностями переделать по себя это легче. Но иногда возникают проблемы с порядком а иногда и вообще не вызывать деструктор предка, если все нужные действия предусмотреть в наследнике.
В>[...]
S>> Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

В>Ты не путай меня, все равно не отвертишься Какие еще ссылки на объекты базового класса? Давай код.
Не хочу искать.

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

S> Да меня на данном этапе Native Delphi вообще не волнует так же как и Борланда.

И это правильно

[...]
S> Это гибкость не языка а компилятора.

Без комментариев...

[...]
В>>Хотелось бы ручками делать Free? Так что там, кстати, с порядком вызова деструкторов? А они там вообще есть? На 90% совместим, говоришь?
S> А Free тебе по любому вызывать придется для освобождения системных ресурсов.
S>С вызовами деструкторов все так же как и в Delphi.

С той только разницей, что такие "финализирующие" методы никто не пытается обзывать их деструкторами

[...]
S>Но иногда возникают проблемы с порядком а иногда и вообще не вызывать деструктор предка, если все нужные действия предусмотреть в наследнике.

Ужас какой... И такое вытворяют на языке, прародителем которого считают Вирта...

В>>[...]
S>>> Ну уничтожу я хип, а там ссылки на объекты базового класса и что дальше???? Это только один из примеров.

В>>Ты не путай меня, все равно не отвертишься Какие еще ссылки на объекты базового класса? Давай код.
S> Не хочу искать.

И не ищи. Забудь как страшный сон.