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

Цитата --Ins-- @ 09.01.14, 12:15

Потому что они доселе это не видели и не понимают как это работает

Видели, понимают и отвергают - D_KEY уже цитировал из книжки по Java.

Цитата --Ins-- @ 09.01.14, 12:15

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

Как-то ты довольно сурово про паскалистов/дельфистов. Я всё-таки надеюсь, что у них ситуация получше и не всё потеряно

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

Ну, это логично. Было бы хуже, если бы деструктор не вызывался.

Да. Правда сначала я удивился, если быть честным.

Цитата trainer @ 09.01.14, 12:01

Ну это просто повезло, пример-то тестовый.

Не спорю, но

Цитата trainer @ 09.01.14, 12:01

Сам объект в куче все еще существует, не перезатерт другим объектом.

Указатель же просто хранит адрес. Если там будет другой объект, какая разница, это же просто участок памяти?
Как рантайм узнает, можно ли по этому указателю обратиться или нет, если там будет другой объект?

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

Цитата OpenGL @ 09.01.14, 12:15

Ну что в Дельфи все не как у людей мы уже поняли

Да ради бога Зато это зачастую удобно И там, где ты начнешь плодить фабрики или приватные конструкторы с кучей параметров, я запилю один виртуальный метод

Цитата --Ins-- @ 09.01.14, 12:18

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

Пример можно?

Цитата --Ins-- @ 09.01.14, 12:18

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

fixed

Цитата korvin @ 09.01.14, 12:18

Если там будет другой объект, какая разница, это же просто участок памяти?

Если там будет другой объект или вообще память будет отдана ОС, то вероятность получить AV или какую другую радость возрастает по моим субъективным ощущениям.

Сообщение отредактировано: trainer - 09.01.14, 12:21

Цитата korvin @ 09.01.14, 12:18

Как рантайм узнает, можно ли по этому указателю обратиться или нет, если там будет другой объект?

Ес-но никак. Это же невалидная ссылка и результат непредсказуем. В лучшем случае - AV

Цитата OpenGL @ 09.01.14, 12:19

Цитата --Ins-- @ 09.01.14, 12:18

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

Пример можно?

Кстати, мы с нетерпением ждём.

Цитата OpenGL @ 09.01.14, 12:19

Пример можно?

Можно. У базового класса есть какое-либо поле, оно нужно в именно этом классе, т.к. его методы к нему обращаются. Значение этого поля у разных потомков должно быть различным, т.е. создать его в конструкторе нашего базового - нельзя, это нужно делегировать потомкам. Более того, его может быть придется не только создать, но и проинициализировать тоже по-разному, например если это контейнер - заполнить его значениями и т.д. Используя полиморфное конструирование я сделаю в конструкторе вызов MyField := CreateMySuperPuperField(); - где последний - виртуальный абстрактный метод. Без этого тебе придется городить фабрику и обязать клиентов создавать экземпляры только с помощью фабрик. А у меня сам конструктор - это фабрика

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

Цитата --Ins-- @ 09.01.14, 12:18

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

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

Цитата Wound @ 09.01.14, 12:46

А то с таким подходом, зачем вообще все эти парадигмы и паттерны, ООП разные нужны?

Так это и есть паттерны - инстанцирующие, всякие там фабрики, фабричные методы и т.д. Только реализованы не так, как ты бы сделал в с++. А что, паттерны накладывают какие-то ограничения на реализацию?

Цитата --Ins-- @ 09.01.14, 12:49

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

Да, и зачем это все использовать, если проще написать все в одной функции. Меньше букв.

Цитата --Ins-- @ 09.01.14, 12:49

А что, паттерны накладывают какие-то ограничения на реализацию?

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

Цитата Wound @ 09.01.14, 12:53

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

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