Разжирели или грустно, товарищи.

[GunSmoker]

P.S.

все любят говорить что VCL крива

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

Библиотечка-то сама по себе не плоха. Удобна, логична. Да, старовата. Да, новых фишек нет. Да, можно модернизировать и улучшить. Но прям вот так: "крива"? Увольте.

Крива - это, скорее, Indy или KOL. Причём, если первая - это просчёт, то последняя - там это сделано специально, цель такая (это я про её лозунг "нет виртуальности").

[Пепел Феникса]

а я не говорю что она кривая

кстати порой люди пытаются свалить кривость/неумение своих рук на другие.(никого не обвиняю, и не на кого не намекаю)

[Alex Cones]

По сути, заметный недостаток у неё только один - малая возможность кастомизации.

Странно, я считал её главным недостатком другое - бесконечное глубинное наследование.

TObject

TPersistent

TComponent

TControl

TGraphicControl

TImage

И у каждого свои свойства\методы, да пока TImage создастся - год пройдет. Нельзя было в конечной версии обрать "предков" и написать конечный класс для TImage? Уж не помню кто, KOL или JEDI, но так и сделали. И ничего, работает... В 5-раз быстрей и в 10 раз меньше размером.

[GunSmoker]

Ох, ну вот вернитесь к этой теме через годика два-три - мож яснее станет (а в промежутке - читать умные книжки. Например - Code Complete).

(Нафига нам вообще классы? Давайте на процедурах писать, чего уж там)

[still_alive]

Что-то тема разжирела...)

Процесс разработки и оптимизации выглядит примерно так:

#include <tdd>
#include <beer>
#include <luck>
#ifdef RELAX
#include <poker>
#include <girls/brunettes>
#endif

...

while (!is_work(program)) {
  drink_and_print("WTF?!");
  write_unit_test();
  make_it_work();
  refactor_bydlocode();
}
while (client_is_not_angry() && program.too_slow()) {
   kill_somebody();
   What reason = profiler_please_help_me();
   switch (reason) {
   case STUPID_ARCHITECT: change_architecture_and_technologies(); break;
   case STUPID_PROGRAMMER: change_algorithms_and_data_structures(); break;
   default: call(Alex_Cones);
   }
   change_stupid_mans();
   kill_somebody_else_just_for_fun();
}
if (client_is_angry() && program.too_slow()) print("oh my god: epic fail");
else print("yeeeew PROFIT $$$");

[spamer]

Нельзя было в конечной версии обрать "предков" и написать конечный класс для TImage?

Вы предлагаете в конечном счете для каждого нового класса писать один и тот же код по десять раз? Или я чего-то не понял...
Если уж так, то очнитесь - это ООП...

[Alex Cones]

Нафига нам вообще классы? Давайте на процедурах писать, чего уж там

Видимо Вы все таки изучили мой стиль написания программ и уже ознакомились с GRAY FUR.

[GunSmoker]

Видимо Вы все таки изучили мой стиль написания программ и уже ознакомились с GRAY FUR.

Нет. Просто это типичная проблема "типа программистов", не открывавших книжки (флёнов и ваша первая книжка не считается) - они просто не знают ООП. Поэтому они не понимают, что тут делает эта иерархия. Поэтому, конечно же, они говорят: "сейчас я напишу свой код с блекджеком и шлюхами!"

[Пепел Феникса]

(Нафига нам вообще классы? Давайте на процедурах писать, чего уж там)

а он так и пишет библиотеку свою.

классы/наследование дают возможность гибкого наращивания функционала.

TObject - база
TPersistent - в первую очередь дает Assing, гибкое копирование объектов
TComponent - дает взаимодействие с классами TReader/TWriter, что позволяет сохранять компонент в файл и обратно, а также имя и св-во Tag.
TControl - дает некоторые события, св-ва координат и тп
TGraphicControl - дает канву, а так же позволяет Parent рисовать себя
TImage - ну собственно дает уже полноценные св-ва по работе с изображением(загрузка растягивание и тп)

чтото из этого еще дает перечисление детей(и соответственно регистрацию детей у родителя)

что из этого хочешь выкинуть?

Алекс я со своим ООП спокойно могу написать File<<Edit, File<<Memo, File<<int и твердо знаю что оно сохранится в файл так как надо, и потом могу спокойно его загрузить обратно.
небольшая универсальность, и кстати значительно сокращает код(не нужно писать спец процедуры подо все варианты компонентов.

[Пепел Феникса]

дубль таки