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

[--Ins--]

Цитата D_KEY @ 13.02.13, 11:33

Как ты можешь обеспечить инварианты реализации базового класса, если тебе даже знать о них не положено?

Так же, как и в случае любого вызова виртуального метода из базового класса

Добавлено 13.02.13, 11:36
PS: достало уже по шестому кругу. Смените пластинку.

[D_KEY]

Цитата --Ins-- @ 13.02.13, 11:35

Так же, как и в случае любого вызова виртуального метода из базового класса

В случае любого вызова виртуального метода у меня нет задачи обеспечения инвариантов реализации базового класса. А в процессе конструирования - есть.

[--Ins--]

Цитата D_KEY @ 13.02.13, 11:36

А в процессе конструирования - есть.

Невелика проблема. Все, что нужно на этапе конструирования - создай зараннее. Если вдруг забудешь - первая же отладка тебе о этом скажет. И стек вызовов будет красноречив, на все про все уйдет 1 минута. И ты успешно это разрулишь и пойдешь дальше. А гибкость никуда не исчезнет

Сообщение отредактировано: --Ins-- - 13.02.13, 11:40

[D_KEY]

Цитата --Ins-- @ 13.02.13, 11:35

достало уже по шестому кругу. Смените пластинку.

Ну так я leo отвечал. Он не в курсе наших кругов и я надеялся на что-то новенькое от него
А что еще обсуждать? Delphi догнивает(хотя работы, думаю, хватит еще не на одно десятилетие ), C++ несколько изменил нишу, но живет и развивается достаточно правильно. Думаю, история нас уже рассудила. В Java и C# хоть и можно делать виртуальные вызовы, но это делать не рекомендуют.

[Flex Ferrum]

Цитата --Ins-- @ 13.02.13, 11:35

PS: достало уже по шестому кругу. Смените пластинку.

А что делать? Вы позиционируете виртуальные вызовы из конструкторов и деструкторов как полезную фичу. Вам показывают, что это приводит к достаточно хитрым дизайн-ликам (как-то: появляется возможность работы с недоконструированными и полуразрушенными объектами), и разработчики на эти лики напарываются, и вынуждены подставлять костыли, чтобы всё работало. Ну, блин, свойство у этой фишки такое!

[D_KEY]

Цитата --Ins-- @ 13.02.13, 11:39

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

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

Цитата

А гибкость никуда не исчезнет

Нет тут никакой гибкости

[--Ins--]

Цитата Flex Ferrum @ 13.02.13, 11:39

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

Я не считаю что возможность управлять очередностью вызовов базового конструктора является костылем. По очень простой причине: метод Create при его выполнении в Delphi ничем не отличается от любого другого, а в любом другом управление такой очередностью тоже не является костылем. Как уже правильно заметили, это в терминологии с++ не совсем конструктор. И я вправе сам решать в каком порядке мне инициализировать свой экземпляр

Сообщение отредактировано: --Ins-- - 13.02.13, 11:44

[Flex Ferrum]

Цитата D_KEY @ 13.02.13, 11:42

Что-то последнее время прихожу к выводу, что отладка - уже следствие неправильно организованных процессов и "лишних" косяков

+100500. В идеале, неправильно работающая программа не должна скомпилироваться.

Добавлено 13.02.13, 11:45

Цитата --Ins-- @ 13.02.13, 11:43

Я не считаю что возможность управлять очередностью вызовов базового конструктора является костылем. По очень простой причине: метод Create при его выполнении в Delphi ничем не отличается от любого другого, а в любом другом управление такой очередностью тоже не является костылем. Как уже правильно заметили, это в терминологии с++ не совсем конструктор

Ответь на простой вопрос: в понимании Delphi'ста в какой момент объект считается полностью созданным? До или после вызова Create? В C++ с этим полная определённость: если конструктор отработал, то объект создан. Если не отработал - то нет. А в Delphi?

[D_KEY]

Цитата --Ins-- @ 13.02.13, 11:43

метод Create при его выполнении в Delphi ничем не отличается от любого другого

Отличается тем, что передаваемый объект находится в "состоянии" отсутствия гарантий соблюдения инвариантов.

[--Ins--]

Цитата Flex Ferrum @ 13.02.13, 11:43

Ответь на простой вопрос: в понимании Delphi'ста в какой момент объект считается полностью созданным? До или после вызова Create?

Трудно сказать. Физически - после выполнения NewInstance. Смотря в каком контексте мы подразумеваем слово "полностью созданный"

[Flex Ferrum]

Цитата --Ins-- @ 13.02.13, 11:48

Трудно сказать.

Но нужно! Ведь это важно!

Цитата --Ins-- @ 13.02.13, 11:48

Физически - после выполнения NewInstance. Смотря в каком контексте мы подразумеваем слово "полностью созданный"

С ним можно работать, вызывать его методы и т. п. В общем, это тот момент, когда объект становится операбельным для клиента.

[--Ins--]

Цитата Flex Ferrum @ 13.02.13, 11:51

С ним можно работать, вызывать его методы и т. п. В общем, это тот момент, когда объект становится операбельным для клиента.

После вызова NewInstance объект представляет из себя именно объект, а не просто участок памяти. Другое дело, что он еще не инициализирован. Является ли это состояние доступным для вызова методов и т.д. - это определяет программист. Если он предусмотрит инвариант все обнулено - то можно сказать что с этого момента. Здесь нет четкой грани, все в руках проектировщика. Но как правило объект готов ко всем вызовам после Create. Возможность получить на этом этапе вызов, который работает не с тем состоянием объекта, на который мы расчитывали - возможен. Но это легко разрулить. И строго говоря, так же легко и не допустить даже не вдаваясь в подробности реализации базового класса

[Flex Ferrum]

Цитата --Ins-- @ 13.02.13, 11:56

После вызова NewInstance объект представляет из себя именно объект, а не просто участок памяти. Другое дело, что он еще не инициализирован. Является ли это состояние доступным для вызова методов и т.д. - это определяет программист.

Ясно. Собственно, именно из этого и растут ноги у FreeAndNil, а также проверки незанулённости (по факту - допустимых инвариантов) на входе в методы. Поскольку дизайн допускает оперирование "полусозданными" (и "полуразрушенными") объектами, и оставляет доведение этих объектов до операбельного состояния на совести клиента, то отсюда и высокий уровень error prone. Фишка в том, что клиент (строго говоря) хоть и должен что-то, но не обязан. И если при конструировании это ещё можно более-менее проконтролировать, то вот при разрушении - гораздо сложнее. В реальной жизни (больших системах с кучей потоков, взаимосвязанных сущностей и т. п.) даже с полными гарантиями возникают ситуации, когда требуются ухищрения для того, чтобы развязать клубки связей между объектами. А когда ещё и дизайн языка в этом не помогает - это совсем аллес и ахтунг...

Добавлено 13.02.13, 12:06
И вместо того, чтобы спокойно писать программы в "контрактном" стиле, ваши программисты вынуждены защищаться от самих себя, от собственных и чужих ошибок "неверного использования", "случайного вызова" и прочего.

[--Ins--]

Цитата Flex Ferrum @ 13.02.13, 12:05

Собственно, именно из этого и растут ноги у FreeAndNil, а также проверки незанулённости (по факту - допустимых инвариантов) на входе в методы.

Я по прежнему считаю что они растут из-за кривизны рук. Найди в коде VCL хоть одну такую проверку? Сомневаюсь, что найдешь. Можно проектировать не думая, и тогда да, без подобных "на всякий случай" не обойтись. А можно подходить ответственно и быть спокойным

[Мяут-Настоящий]

Цитата --Ins-- @ 13.02.13, 12:10

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

Если язык привносит дополнительные места, где надо думать, это разве хорошо? Проектирование вообще не должно думать про AfterConstruction и NewInstance всякие