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

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

Код на Java

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

// Как мне тут положить в List элементы?

Ну наверное надо было положить элементы раньше:

class Derrived extends Base {
  public Derrived() {
    List list = new ArrayList();
    // Ложить в List элементы тут
    super(list);
  }
}

В общем, у нас тут опять то же, что было в многочисленных "тогда"

Цитата OpenGL @ 09.01.14, 14:20

Да и вообще, ситуация, когда базовому классу необходимо знание дочернего

А где тут базовому классу необходимо знание дочернего?

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

Цитата Мяут-Настоящий @ 09.01.14, 14:22

Ну наверное надо было положить элементы раньше:

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

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

--Ins--, есть хороший конкретный пример?

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

Нередко это аккуратненько так прячется за pimpl'ом и наружу не торчит

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

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

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

Потому что это костыль - протектед сеттер только для того, чтобы иметь доступ в конструкторе

Костыль - это вызывать методы ещё не созданного или уже разрушенного объекта.

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

Во-первых, пример?

Да хотя бы то же Qt. Там все классы, которые торчат "наружу" - по сути, фасадные.

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

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

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

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

Костыль - это вызывать методы ещё не созданного или уже разрушенного объекта.

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

class function CreateMyField: TList; virtual abstract;

Ы?

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

Да хотя бы то же Qt. Там все классы, которые торчат "наружу" - по сути, фасадные.

Я в курсе, но там это сделано для бинарной совместимости. При чём тут двухэтапное контруирование?

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

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

Скажем так: переопределение виртуальных методов - это не двухэтапное конструирование.

Цитата Мяут-Настоящий @ 09.01.14, 14:22

Ну наверное надо было положить элементы раньше:

Не, в джаве это не прокатит, там super должен идти первым выражением.

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

Нет, костыль - это сеттер спешиал фор конструктор

Нет, костыль - это вызывать методы ещё не созданного или уже разрушенного объекта.

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

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

И как абстрактный метод спасает от такого вызова?

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

Я в курсе, но там это сделано для бинарной совместимости. При чём тут двухэтапное контруирование?

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

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

Скажем так: переопределение виртуальных методов - это не двухэтапное конструирование.

Всё зависит от методов...

Цитата korvin @ 09.01.14, 14:31

Не, в джаве это не прокатит, там super должен идти первым выражением.

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

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

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

И как абстрактный метод спасает от такого вызова?

Он не только абстрактный, он еще и классовый

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

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

Нет, костыль - это вызывать методы ещё не созданного или уже разрушенного объекта.

А я не вызываю методы объекта Метод классовый Так что твой костыль остался, а моего нет

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

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

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

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

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

Всё зависит от методов...

Ну, так пример, пример!

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

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

А я не вызываю методы объекта Метод классовый

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

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

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

А где тут базовому классу необходимо знание дочернего?

private поле (а значит, доступное только базовому классу) необходимо заполнять в зависимости от того, какой это на самом деле класс. В конструкторе. Что это, если не требование знать конкретный тип?

Добавлено 09.01.14, 14:38
А вот кстати насчет виртуальных статических методов соглашусь - они могли бы быть полезны

Цитата OpenGL @ 09.01.14, 14:37

private поле (а значит, доступное только базовому классу) необходимо заполнять в зависимости от того, какой это на самом деле класс. В конструкторе. Что это, если не требование знать конкретный тип?

Где тут требование знать конкретный тип? Базовый класс не оперирует никаким знание о потомках, он обращается только к своему интерфейсу. Чем это принципиально отличается от обычного полиморфного вызова, где базовый класс точно так же делегирует выполнить действие потомку, но при этом дергает за свой интерфейс?

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

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

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

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

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