Есть ли будущее у DELPHI?

Цитата MyNameIsIgor @ 09.01.14, 14:35

Каким образом pimpl aka bridge помогает получить двухэтапное конструирование?

Да очень просто! Ты подумай хорошо. У тебя фасад полностью отвечает за процесс конструирования и инициализации. Ты хоть там десять этапов наверни - всё пройдёт.

Цитата --Ins-- @ 09.01.14, 14:39

Цитата MyNameIsIgor @ 09.01.14, 14:35

Т.е. так и запишем: полиморфизм в конструкторах/деструкторах не нужен. ЧТД.

Так метод виртуальный Классовый, но виртуальный

Ну и что? Речь-то была о том, чтоб не вызвать методы еще несконструированного объекта. Теперь ты это не делаешь

Цитата Flex Ferrum @ 09.01.14, 14:41

Да очень просто! Ты подумай хорошо.

Я то отлично подумал.

Цитата Flex Ferrum @ 09.01.14, 14:41

У тебя фасад полностью отвечает за процесс конструирования и инициализации. Ты хоть там десять этапов наверни - всё пройдёт.

И на всё это уже отвечал. Краткое содержание предыдущих серий: в каком реальном фрэймворке/библиотеке вам приходилось писать наследника с учётом двухэтапного конструирования, приведите пример.

Цитата --Ins-- @ 09.01.14, 14:39

Так он виртуальный

Он не полиморфен относительно объекта. Он зависит от метаобъектного протокола.

Цитата D_KEY @ 09.01.14, 14:43

Ну и что? Речь-то была о том, чтоб не вызвать методы еще несконструированного объекта. Теперь ты это не делаешь

Конструктор от этого не перстает быть полиморфным Да и кстати я и раньше этого не делал - объект на этот момент уже есть. Но не полностью инициализированный

Добавлено 09.01.14, 14:48

Цитата MyNameIsIgor @ 09.01.14, 14:43

Он зависит от метаобъектного протокола.

Он зависит от конкретного класса создаваемого объекта и больше ни от чего. Это и есть полиморфизм относительно объекта

Сообщение отредактировано: --Ins-- - 09.01.14, 14:48

Цитата --Ins-- @ 09.01.14, 14:45

Конструктор от этого не перстает быть полиморфным

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

Цитата

Да и кстати я и раньше этого не делал - объект на этот момент уже есть. Но не полностью инициализированный

Мы это уже 100500 раз обсуждали и к согласию не пришли. Пусть попробует кто-нибудь еще

Цитата --Ins-- @ 09.01.14, 14:32

В принципе можно создать статик метод, возвращающий лист, и передавать его в конструктор, но мне страшно представить как такое будет выглядеть если у нас такое поле не одно, а штук пять-десять

На то она и Джава. В более хороших языках всё просто.

Цитата --Ins-- @ 09.01.14, 14:45

Цитата MyNameIsIgor @ 09.01.14, 14:43

Он зависит от метаобъектного протокола.

Он зависит от конкретного класса создаваемого объекта и больше ни от чего. Это и есть полиморфизм относительно объекта

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

И вообще, мне кажется, что мы забываем про base from member - мы можем создать любую фабрику до конструирования предка, он ею своё поле и проинициализирует. Без всякой двухэтапки.

Сообщение отредактировано: MyNameIsIgor - 09.01.14, 14:59

Цитата D_KEY @ 09.01.14, 14:52

Ты вызваешь метод класса, а не объекта.

Это устраняет вашу претензию, но не меняет сути - конструктор остается полиморфным, реализующим абстрактное поведение и делегирующим конкретику своим потомкам И это именно то, что в Delphi делается просто, а в некоторых других языках - не очень

Цитата --Ins-- @ 09.01.14, 14:54

Это устраняет вашу претензию, но не меняет сути

Это лишь показывает, что вы нас всё это время не понимали. Суть наших претензий как раз и сводилась к вызову методов несконструированного ещё объекта, против некой "общей полиморфности" конструктора никто не возражал.

Цитата --Ins-- @ 09.01.14, 14:29

Ы?

И что, переопределенный классовый метод потомка будет иметь доступ к приватным членам родителя? Нет. Чем это тогда отличается от

class Base {
    ...
    protected Base(T1 p1, T2 p2, ...) {
        ...
    }
}
 
class Derived extends Base {
    private static T1 makeP1() {
        ...
    }
    private static T2 makeP2() {
        ...
    }
    ...
    public Derived() {
        super(makeP1(), makeP2(), ...);
        ...
    }
}

?

Цитата --Ins-- @ 09.01.14, 14:54

Цитата D_KEY @ 09.01.14, 14:52

Ты вызваешь метод класса, а не объекта.

Это устраняет вашу претензию, но не меняет сути

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

Цитата --Ins-- @ 09.01.14, 14:23

А в джава так можно? Я думал вызов конструктора предка должен быть первым?

Да, моя ошибка.

Впрочем учитывая шутку 'ProblemFactory' про Java, понятно, какой паттерн джависты бы применяли для описанного тобой случая. Полиморфное конструирование - это фабрика. Я фабрики даже в Python делаю, в котором вообще абсолютная свобода в этом вопросе.

Сообщение отредактировано: Мяут-Настоящий - 09.01.14, 15:10

Цитата D_KEY @ 09.01.14, 15:02

Вот и приводите в качестве аргумента наличие классовых виртуальных методов, а не всякий трешак

Это с какой итерации мы к этому пришли?

Сообщение отредактировано: MyNameIsIgor - 09.01.14, 15:16

Цитата --Ins-- @ 09.01.14, 14:54

реализующим абстрактное поведение и делегирующим конкретику своим потомкам

Следи за руками. =) И можно использовать не только классовые функции. =)

Сообщение отредактировано: korvin - 09.01.14, 15:22