О VCL

Под влиянием "новомодных" тенденций слышу иногда "ах VCL это уже не модно, ах он должен вымереть как динозавры".

Если интересна МОЯ точка зрения - СКАЖУ - VCL по "архитектурности" и "практической вылизанности" - ЛУЧШАЯ библиотека, которую я видел.

А сравнивать - ЕСТЬ с чем - TurboVision, SuperVision, OWL, MFC, QT, UIKit. Что ещё забыл?

Ах да! FireMonkey! Я в FireMonkey пока ГЛУБОКО не погрузился, но я видел VGScene (предтеча FireMonkey) и ОСНОВАТЕЛЬНО ей переделывал.

Что сказать про FM? "АРХИТЕКТУРНО" она мне нравится БОЛЬШЕ, чем VCL. Концепция стилей, слоёного пирога и ОБЩЕЙ канвы - МНЕ СИЛЬНО нравятся.

Но пока FireMonkey - проигрывает VCL по "вылизанности" и стабильности. Но я думаю - "парни справятся с этой проблемой".

Я если найду время - начну глубоко погружаться в FM и тогда буду писать свои КОНКРЕТНЫЕ впечатления, замечания и рецепты по улучшению.

У меня есть "пара идей", которые я бы хотел сделать на FM. Правда у меня основной работы "вагон и маленькая тележка". Но я надеюсь, что я найду время.

Ну и раз уж я начал сравнивать - скажу ещё одно впечатление - КОНЕЧНО UIKit. Он - ХОРОШ. Особенно "для чайников". В нём МНОГО чего уж есть априори. И в нём есть "стройность концепции". Местами "кривая" лично для меня, но стройность и единообразие.

НО VCL - пока - лучший. Но с него - рано или поздно - всё равно надо слезать. Мне так почему-то кажется.

Где-то за неделю перепортировал все проекты с XE3 на XE4

Где-то за неделю перепортировал все проекты с XE3 на XE4.

Они - СОБИРАЮТСЯ. Но пока ничего - НЕ РАБОТАЕТ из-за -http://18delphi.blogspot.com/2013/05/xe4.html

Жду теперь когда Resolved превратится в Closed.

P.S. я кстати нашёл ТРИ workaround'а ошибки. Попробую завтра всё же ЗАПУСТИТЬ простейшие тесты под XE4. РУКИ ЧЕШУТСЯ на это посмотреть.

Метания с Indy XE3 vs. XE4 - страннЫ

Метания с Indy XE3 vs. XE4 - страннЫ.

To const array of  bytes, to TidBytes, то опять const array of  bytes.

Неаккуратненько. Прямо скажем.

!!!! Resolved говорят

http://qc.embarcadero.com/wc/qcmain.aspx?d=116040

Только я не понял - почему Build - None?

"Дырявые абстракции" и property

http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html

Есть property X : Integer read GetX write SetX.

И есть метод doSomething (var X: Integer)

ТУДА property передать НЕЛЬЗЯ!

Почему спрашивается?

Почему нельзя сделать compiler-magic типа

l_X := SomeObject.X;
SomeMethod(l_X);
SomeObject.X := l_X;

???

Зачем разрывать "дырявые абстракции"?

Чтобы "взорвать мозг программистам"? Или просто "не додумали"?

Или ЕЩЁ пример.

property X: SomeRecord

ПОЧЕМУ нельзя написать SomeObject.X.SomeField := SomeValue? Тоже, чтобы "разорвать абстракцию" или взорвать мозг программистам?

Почему нельзя сделать compiler-magic:

l_Rec := SomeObject.X;
l_Rec.SomeField := SomeValue;
SomeObject.X := l_Rec;

???

НЕ ПОНИМАЮ....

Я бы на месте Embarcadero "это" сделал бы...

P.S. Если уж сделали ARC в виде compiler-magic, то и ТУТ бы я это сделал бы...

Вот это - расстраивает...

http://qc.embarcadero.com/wc/qcmain.aspx?d=110364

Хотя... Если я правильно понял - может быть РАДУЕТ... Буду пробовать...

reference to совместимо с МЕТОДАМИ ОБЪЕКТОВ?! А с ЛОКАЛЬНЫМИ процедурами?! Если - ДА, то - РАДУЕТ! Буду пробовать.. у меня - ЕСТЬ НА ЧЁМ...

Не могу пока написать "перехожу на Delphi XE4"

Не могу пока написать "перехожу на Delphi XE4".

Потому, что вот - http://18delphi.blogspot.com/2013/05/xe4.html

ОЧЕНЬ хотел бы написать такое....

P.S. Пока буду добиваться того, чтобы заработали ВСЕ тесты под XE3. Там похоже "мои" косяки в основном.

Offtopic. Google зовёт "зарабатывайте на блоге"

"

Здравствуйте! Хотите зарабатывать на своих сообщениях в Blogger? Это возможно с AdSense – простой и понятной рекламной программой Google, встроенной в Blogger. AdSense позволяет зарабатывать на контекстных рекламных объявлениях, которые появляются рядом с Вашими сообщениями в блоге. В прошлом году владельцы сайтов и блогов, использующие AdSense, заработали более 7 млрд долларов – выгода очевидна."

Это вообще комильфо? По-моему - не очень...

Надо по-моему СИЛЬНО различать "желание донести свои мысли до других" и "желание заработать"... Как-то так...

Объекты "старого стиля" в XE4

Нет, я конечно "уважаю Остап Ибрагимыча". И читал в программном документе (http://18delphi.blogspot.ru/2013/04/delphi-language.html) постулат об отказе от object.

Но то, что "сотворили" в XE4 с object'ами (по сравнению с record'ами с методами) - выглядит скорее как ОШИБКА, нежели чем ЧЁТКО СПЛАНИРОВАННОЕ действо. Это - грустно.

Методы на record'ах, которые возвращаются из property - МОЖНО звать, а на object'ах, который возвращаются, через property - НЕЛЬЗЯ. Глупо имхо. Тем более, что пишут "var reference required". Ну ГЛУПО! Про property и var - я давно кстати пост хочу написать. НАПИШУ.

P.S. Embarcadero (нашему надёжному "причалу") тут ТВЁРДАЯ "двойка" (учитывая ещё и вот это - http://18delphi.blogspot.com/2013/05/xe4.html). ИМХО. НЕЛЬЗЯ выпускать НОВЫЙ компилятор в течении полу-года от старого. Тем более с ТАКИМИ различиями. Я бы СЕБЕ этого не позволил бы. Но я надеюсь, что "парни учтут ошибки и постараются так больше не делать".

Я то конечно - "выкрутился". Но только то, что ВЕСЬ интересующий код был нарисован в UML и то, что была возможность поправить ШАБЛОНЫ КОДОГЕНЕРАЦИИ - позволило решить проблему за ОДИН РАБОЧИЙ ДЕНЬ. Object я теперь генерирую в record, наследование в агрегацию, а методы, где не срасталось с наследованием сгенерировал в overload-Stub'ы. Если бы этого не было бы - думаю разборки затянулись бы на неделю.

Правда IfDef XE4 повсеместно это - УЖАС. Но по-другому - пока не так. Ведь существует масса проектов, которые пока на Delphi 7 приходится собирать.

Я бы на месте Embarcadero подумал бы о возвращении полноценного object. Хотя бы под директивой компилятора. Тем более, что отмазка "в LLVM такого нет" - не катит. Всё там есть. Достаточно на xCode посмотреть.

Теперь осталось дождаться момента - когда Embarcadero поправит ошибку с "открытыми массивами".

KOL и XE4

KOL и XE4.

Грустная история... Порезали полноценную поддержку object. Так что KOL - RIP. Для XE4.

В XE3 - ещё было всё хорошо.