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

Цитата Астарот @ 10.03.13, 09:08

И там противоположностью ShowCaretProc является HideCaret ???

Если под "и там" подразумевается Борландовская VCL, то в ней вовсе нет подобных методов (я же сказал - кроме TControl.XXX).

Цитата Flex Ferrum @ 10.03.13, 18:38

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

Видимо, да. Причем, не исключено, что эта супер-идея осенила "Архитектора" уже после создания базового эдит-контрола с его property ShowCaret:boolean - поэтому и пришлось обзывать метод ShowCaretProc, дабы обойти конфликт имен

Цитата Flex Ferrum @ 10.03.13, 18:38

Я не знал. Но все равно для меня это несколько странно...

А что конкретно? Root - это уже примочка TFMXObject. Что означают и для чего используются (или могут использоваться) ComponentCount и ComponentIndex описано в справке (другое дело, что в самой VCL ComponentIndex практически не используется, и введен скорее "на всякий случай" по аналогии с элементами коллекций и т.п.). Ну а FieldAddress, MethodAddress и понятие published полей, свойств и методов - это, можно сказать, "краеугольный камень" дельфийской модели сохранения и загрузки компонентов из ресурсов. Можно, пытаться спорить, для чего эти методы сделаны публичными, или почему они объявлены именно в базовом классе TObject, а не в TComponent, или, что вообще эту задачу можно было решить по другому. Но Борланды'ы в свое время решили ее именно так, путем расширения модели ООП в сторону published - возможности доступа к полям и методам по их именам через RTTI. Поэтому, хотя конструктор базовой формы TCustomForm сам по себе ничего не знает о своих наследниках (как и "положено"), тем не менее, будучи вызван от имени формы-наследника и заглядывая в dfm-"шпаргалку" из ресурсов и в RTTI, нормально конструирует и инициализирует все поля и свойства формы-наследника (о, ужас!)

Цитата leo @ 10.03.13, 22:52

Причем, не исключено, что эта супер-идея осенила "Архитектора" уже после создания базового эдит-контрола с его property ShowCaret:boolean - поэтому и пришлось обзывать метод ShowCaretProc, дабы обойти конфликт имен

А переименовать проперть в IsCaretShown (что было бы, на мой взгляд, правильней) - рука не поднялась. Или, если иначе, после переноса методов в TFMXControl переименовать в ShowFocusRect/HideFocusRect (что, судя по некоторым другим методам в этом же классе, было бы логичнее) - тоже не догадались.

Цитата leo @ 10.03.13, 22:52

А что конкретно?

Ну, лично на мой вкус:
1. Относительно FieldAddress/MethodAddress - а кто гарантирует, что метод будет позван с нужным числом параметров правильных типов? Или по полученному адресу будет записано значение именно ожидаемого типа? Не, борландовцы, конечно, ребята лихие. Помниццо, когда они OWL 1.0 делали (это ещё до Delphi и VCL было), они обработчики виндовых событий реализовали путём "хака" виртуальной таблицы классов - к каждому методу можно было добавить атрибут, идентифицирующий виндовое сообщение, которое этот метод должен был обрабатывать. Мило так.
2. Относительно ComponentIndex/ComponentCount - проблемы две. Первая: отсутствует консистентность в именовании. Вторая: модификация списка контролов в родительском компоненте приводит к реиндексации всех его непосредственных потомков. Для такой пессимизации должна быть веская причина.

Цитата Flex Ferrum @ 11.03.13, 07:39

Ну, лично на мой вкус:

Ну я ж намекнул, что дискутировать о вкусах логичнее в продожение баталии "Delphi vs C++"
FieldAddress/MethodAddress - это элемент "дельфийской демократии и открытого published общества" В частности в справке к "разумно-демократичной" Delphi 7 черным по белому сказано, что MethodAddress используется internally by the streaming system, и не для вызова метода, а лишь для присвоения адреса обработчика события по имени метода - при этом корректность присваивания гарантируется компилятором, который проверил его в дизайн-тайме и записал в dfm-ресурс. И тут же приписка для "пытливых умов и шаловливых ручек": There should be no need to call MethodAddress directly. (Чем это не "контракт"? Или он обязательно должен связывать по рукам и ногам, кабы чё не вышло?). А вот "разгульно-анархическая квази-демократия" ЕМБ-шного XE, почему-то не только ни слова не говорит об internal use этого метода, но еще и "со смаком" расписывает как его можно и нужно юзать в рантайме для сомнительных хак-манипуляций .

Цитата Flex Ferrum @ 11.03.13, 07:39

Относительно ComponentIndex/ComponentCount - проблемы две. Первая: отсутствует консистентность в именовании

А, нпаример, в виндовых GetMenuItemCount и GetMenuItemID - она присутсвует?

Цитата Flex Ferrum @ 11.03.13, 07:39

Вторая: модификация списка контролов в родительском компоненте приводит к реиндексации всех его непосредственных потомков

В том-то и причина неиспользуемости свойства ComponentIndex на чтение, что оно не хранит индекс в самом компоненте, а просто ищет себя в списке Components своего владельца по указателю. Хоть это и получается чуть быстрее за счет использования приватных методов, чем специальный перебор public Components[i], но на практике используется редко, т.к. чаще идентификация того или иного компонента требуется именно в цикле по Components[i] и проще\быстрее использовать сравнение указателей в самом цикле. Ну а изменение ComponentIndex, в принципе, может использоваться - в частности оно предусмотрено в TForm.SetChildOrder и может юзаться, например, в дизайн-тайме для упорядочивания Creation Order "хаотически набросанных" компонентов

Цитата leo @ 11.03.13, 09:18

FieldAddress/MethodAddress - это элемент "дельфийской демократии и открытого published общества" В частности в справке к "разумно-демократичной" Delphi 7 черным по белому сказано, что MethodAddress используется internally by the streaming system, и не для вызова метода, а лишь для присвоения адреса обработчика события по имени метода - при этом корректность присваивания гарантируется компилятором, который проверил его в дизайн-тайме и записал в dfm-ресурс. И тут же приписка для "пытливых умов и шаловливых ручек": There should be no need to call MethodAddress directly. (Чем это не "контракт"? Или он обязательно должен связывать по рукам и ногам, кабы чё не вышло?).

Ну, нормальный контракт, чо! Конечно, не обязан. Но если может - будет плюсом.

Цитата leo @ 11.03.13, 09:18

А, нпаример, в виндовых GetMenuItemCount и GetMenuItemID - она присутсвует?

Ага. Почитай внимательно описание этих методов. Оба адресуют дочерние элементы заданного хендлом меню. Чувствуешь разницу? Да и ID - это не совсем Index. Но можешь, конечно, списать на вкусовщину.

Цитата leo @ 11.03.13, 09:18

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

Ясно. Значит, оставили на всякий случай.

Вообще я сам никогда не мог понять, почему все методы TObject объявлены как public. Там половину если не в приват нужно было засунуть, то хотя бы в protected. А методы FieldAddress/MethodAddress я бы вообще не делал, класс предоставляет RTTI, а ковыряется в нем пусть сам сериализатор. Сериализация в VCL - действительно крайне кривая, что дало лично мне кучу поводов для написания собственных велосипедов

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

Как дельфисты представляют себе ООП

Цитата leo @ 13.03.13, 10:55

Цитата violation @ 13.03.13, 06:31

Как сюда можно присобачить ООП?

Оно у тебя уже "присобачено", т.к. форма "Сотрудники" это и есть отдельный класс\объект

Цитата [S]mike @ 13.03.13, 12:42

Как дельфисты представляют себе ООП

Каков вопрос, таков и ответ

PS: А ссылки на вопрос\ответ ты, почему-то битые привел, совсем не в ту степь. Случайность или осваиваешь искусство ООПровокации?

Я думаю, что leo нормально представляет себе ООП, скорее просто в силу различных причин решил дать чисто программистский ответ - сколь точный, столь и бесполезный

Цитата leo @ 13.03.13, 17:15

PS: А ссылки на вопрос\ответ ты, почему-то битые привел, совсем не в ту степь. Случайность или осваиваешь искусство ООПровокации?

Это просто форум почему-то не умеет давать ссылку в цитате, если исходное сообщение в другом форуме

http://runrev.com/newsletter/june/issue111/newsletter4.php
Еще одна история успеха Дельфей

[S]mike, а чё там? Я ни чё не понял

ЧТо же не понятного - 100 000 строк на Дельфи против 30000 строк на Лив Коде. При этом на Лив Коде всего около полутора десятков "платформенно-зависимых".

Да это же просто праздник какой-то!

Цитата

deks спасибо за обзор,
все мои опасения подтвердились, и вырисовывается следующая картина, схожая по симптомам c win-версией:
в fmx так и ничего не поменяли, не оптимизировали, не убрали баги,
просто тупо компилят тот говнокод новым (новым ли?) компилятором,
а сама разработка соответственно под ios это просто фэйк, показуха для акционеров....
Xe4, если таковой релиз вообще будет иметь место в апреле - это просто,
как некий инсайдер заметил на delphihaters просто:
"XE3 sales result is just the worse when compared with the last 4 years, Embarcadero needs to release earlier to avoid another layoff before June"

Deks, eсли тебя не затруднит не смог бы ты выложить подобный тест-обзор
на g+, сейчас или потом после теста релизной версии (уверен, что ничего кардинально не будет изменено), дабы поспособствовать концу мучений emb с дельфи,
т.к. четко видно, что текущий менеджмент ПРОСТО убивает delphi, и ей срочно нужно спасение в виде новой команды разработчиков, возрождения в новом виде и т.п.

Цитата

deks
трудно быть оракулом не видя кода, но по аналогии с виндой:
1) долгая загрузка:
компилятся все стандартные шейдеры: shadow, glow и тп.,
на вин-osx они уже скомпилированы, на ios идут в виде текста и компилятся на лету,
2) Много памяти: если отталкиваться от исходников в xe3 - то это просто мрак: в память грузятся одни и те же переменные по нескольку раз, те же шейдеры в виде строк передаются из функции в функцию, битмапы-текстуры сидят как в оперативной памяти, так и дублируются в видео память, причем в некоторых местах по многу раз.
Также возможно, это конечно глупо но, в память могут грузиться и шейдеры от dx9-10, как это сделано на windows, см файлы: FMX.Filter.Standard.pas, FMX.Materials.pas, FMX.Filter.Custom.pas, FMX.Filter.Effects.pas - под виндой грузятся в память шейдеры для osx и ios - видимо просто было лень сделать отдельные файлы?
Также постоянно в fmx нарушается золотое правило - повторяющиеся блоки оформлять в виде функций - имеет место быть многократные повторения кода.
3) Медленная работа: все анимации, биндинги и т.п. устанавливаются через rtti по имени property, т.е. обезьяна не хранит ссылку на конкретное свойство, а ищет их каждый раз его по ИМЕНИ! Мало того что установка через rtti медленна сама по себе, так тут еще и постоянный поиск имен!
Функции вызываются по нескольку раз вложенно, даже там где можно сократить. Идут постоянные копирования в переменные, которые тут же, ниже по коду переписываются другими данными - т.е. оптимизацией как таковой не пахнет вообще!
Еще есть работа со стилями, я так понял автор ее делал на подобии того как это реализовано во флеше, но реализовал он ее через жопу - я даже не стал в них разбираться - мне хреново стало, там тоже идет постоянный поиск по строкам и другие ужасы........
Классы до отказа забиты полями на все случаи жизни, к примеру TControl, который несет в себе контекст для отображения, используется как основа для всех элементов на экране, даже тех которые вообще не требует возможностей этого класса! Каретка перед тем как прорисоваться на экране ищется по ИМЕНИ в списке анимаций среди стилей - этакая пирамида. Отрисовка дочерних элементов - это просто жуть, складывается такое ощущение, что автор потерял целостное видение иерархии отображения, и везде где что то не отрисовывалось - понавставлял кодовых костылей, в итоге получилось что некоторые элементы отрисовываются по нескольку раз, и даже тогда года их вообще не задевают!

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

Цитата

Друзья, вы еще не поняли, все эти говнодемки делаются для показухи:
наши программы в апсторе и все тут: отслюнявте очередные бонусы для боссов,
и не отрывайте от кормушки, все точка!,
Не будет ни каких нормальных программ на fmx для ios!
тем более не будет никакого нормально работающего софта под андроид - будет ограниченно (пара-тройка фич) работать ровно на планшетах и смартфонах - на тех которые есть у разработчиков!
Если все же, кто-то самый отважный, все таки попытается сделать коммерцию на этом горе-фреймворке,
то после первых же отзывов РЕАЛЬНЫХ пользователей, его погонят грязными тряпками из всех апстров и плеев!

http://forum.ru-board.com/topic.cgi?forum=...13387&start=900

Добавлено 05.04.13, 20:21

Цитата

valgreesh
Тоже посмотрел, правда с трудом выдержал поносный бред всеволода всея русо-емб.
И напротив - очень порадовал Ярослав, объяснял все четко, однозначно, без запинок и прочей лабуды присущей первому соведущему, в примерах тоже относительно понятно.
В итого все очень неплохо, можно сказать даже отлично, хочется порадоваться за дельфи, пока конечно речь не дойдет до реальных коммерческих приложений - которым к сожалению СУЩЕСТВОВАТЬ не судьба, до тех пор пока не будет пересмотрен и оптимизирован корневой код firemonkey. Всеволод это тоже понимает, поэтому вопрос по размеру и быстродействию быстренько ПРОПУСТИЛ.
О том что ситуация с быстродействием в XE4 даже под windows, c большой вероятностью не поменяется говорит этот пост: _https://forums.embarcadero.com/thread.jspa?threadID=85426&tstart=0, в нем идет отсылка в частности к тикету _http://qc.embarcadero.com/wc/qcmain.aspx?d=113795, почему то БЛАГОПОЛУЧНО закрытому, в комментах к которому есть след. строка:
Added XE4 Beta 11 results to the document and to the description. Essentially it is the same no improvement. .
Слааабая надежда на какое-либо улучшение в РЕЛИЗЕ конечно имеется, но это будет САМАЯ последняя и САМАЯ слабая надежда......................

http://forum.ru-board.com/topic.cgi?forum=...13387&start=940

Вот он, нативный язык в действии:
https://forums.embarcadero.com/thread.jspa?...=74930&tstart=0

На простейший расчетах от 3 до 13 раз медленнее джавы и плюсов.

[S]mike, интересно было бы почитать, как отзываются бывшие борландовцы о Delphi сейчас. Нет у тебя такой инфы?