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


goto XCL page

goto home page