XCL vs. VCL - bicycle invented again?
by Vladimir Kladov
(C) 1999
Reading
newsgroups, I found one marvelous answer onto bored to death question: "how to program in Delphi using only API calls and without
VCL?". Unfortunately, language of discussion was not
English, so I can not retell it exactly in the same words. I am bringing here question and
answer approximately:
"You, obviously want to make your
program small. This is not too hard. File|New Application, than View|Project Manager,
delete Unit1, than Project|View source, delete Forms from uses clause (You may add here
Window, ShellAPI and Messages), delete lines between begin and end and write there your
code. Be sure, You will obtain very small executable, but without form, even without
button on taskbar. If You will be happy after this - congratulations! But, if You want to
start programming without VCL, You need to study API, and if You want to use advantages of
Object-Oriented Programming, You soon will create your own TForm, TButton, TLabel, and...
You will see, that bicycle already invented!".
I was read it when I already started working under XCL and my XForm, XButton,
XLabel were created already. So I do not agree with answer given to the question. XCL
allows to create programs, which looks like normal Windows applications. Thus is, its can
have forms, button on taskbar, different clever controls on forms and so on. But its size
stays small!
The biggest applet, what I created using XCL, was about 116Kbytes. The
smallest application with form, what could be given using VCL, is 170K (Delphi3) or 270K
(Delphi4). I heard also the opinion, that this is a nuclear kernel, containing all that
could be needed in further working under the project, and later when project is filling
with controls and developer's method, events and so on, size of executable almost does not
growth. Lie! Growth and growth very well! My own experience shows, that every new type of
control, added to project, is eating at least 10Kbytes. And this is yet good indication.
Some controls increase executable twice when added!
I have to say: this is because VCL is created using principal "all that
could be here, is here". But XCL is creating using polar principal: "all that
could be anywhere else then here, is not here". As a result, when developer drops VCL
component or control onto VCL form, joining it to project like a purl, [s]he drag out the
total chain of beads. I.e., all methods, all used components, all its methods, all
components, used in used components and all its methods, ... and so on - right up to the
last grain in house what Jack had built.
But first grow of VCL application starts from great ability of components and
forms to store its [published] properties in executable and to read its state from there
when these are constructed. To be able to do it, bloats of input-output support must be
linked. And bloats of error-handling too, because during reading something strange could
occur. And most of errors must be indicated showing a window with message box. And this is
great too.
And, second, programming in VCL is visual. Do You remember that VCL means
"Visual Components Library"? Visual means that components contain code which
works only at design time. Event handling, painting and some other behavior, including
ability to write state of component into stream are linked here. Yes, components can be
compiled into run-time package, which does no contain design-time behavior. Allegedly. Who
is deciding, what code has no sense at run-time? Developer? No. It is an optimizer,
"who" makes such decision. If the optimizer would be a bit clever, after
clicking File|New application and translating it we always got executable about 500 bytes.
Not 270000 bytes, as it is now.
Since I do not trust to optimizer in police of XCL building. E.g., Canvas for
XWindow class in XCL is declared as Pointer. This allows not to include XCanvases.pas unit
every time but only if this last really needed. And this was the first reason of creating
so-called add-ons, expanding behavior of certain classes in XCL without embedding too many
code into such classes. Only if an add-on used and its initialization procedure is called
directly, it is linked and works. If not, executable stays clean from additional
[kilo]bytes. And only developer is deciding, what [s]he prefer - economy of program size
or additional features.
Yes, there are exist some overhead expenses and when add-on is used, code is
a few bigger than it could be in case of implementing desired feature in class itself,
without the add-on. But, in case when add-on is not used, size of code expended onto class
implementation less sometimes several times.
Add-ons as a method of extending classes, was developed first only to reduce
size of executable, but later became very important part of XCL ideology. In many
situations technique of add-ons allows to avoid creating of new brunch in classes tree by
rewriting of some base classes and expand behavior of existing objects by introducing
additional capabilities into some of its base classes. I think, this subject merits to
discussed in separate article more detailed. At least, I must to say, that add-ons is
something new, what was never seen before in object programming (That's very decent of me,
doesn't it?).
In conclusion of this brief story, I can say, that "yes, bicycle is
invented again, but it has pedals instead of jet engine and with weight several times
less".
29-Sep-1999