Borland's Kylix: turbocharging Linux development - page 4
Not Your Father's TurboPascalGraphical Interface Items Aren't Always Graphical
Real-world programs, unlike sales demos, need to deal with objects and events which have very little to do with the graphical interface and which, in many cases, have absolutely no visible representation. Kylix, as do most other IDEs that I have used, insists on forcing objects such as TCP/IP sockets, action lists, periodic timers, and database connections into little icons that one drops onto the form as if they were GUI components. The upsides of this are that it is very intuitive for a GUI-oriented programmer, and that doing so makes sense when these same objects are also dropped seamlessly into the event model of the GUI (as they are in Kylix). In my personal opinion, however, this makes less sense than having a separate domain for these abstract objects. I would like to see a screen-domain and an event-domain, one defined by space and the other by time, but Kylix does not work that way. In this design choice, I must admit Kylix follows the precedent of other IDEs, so I concede that I am probably in the minority with my opinion. If the pseudo-GUI-ness is a forced relationship, at least it is well implemented and the non-GUI objects behave much as one would expect.
There are also objects for database connections, supporting such popular choices as DB2, Oracle, and MySQL. I have a very recent build of MySQL (3.23.33) installed and tried to use the Kylix objects to connect to it. Unfortunately, Kylix complained that I did not have libmysqlclient.so.6.0.0 installed. In fact, I have libmysqlclient.so.10.0.0 installed. It seems odd that a product which insisted on a glibc no earlier than 2.2 would want such an old MySQL library and refuse to work with a newer one. Perhaps this is resolvable; I tried the usual symlinks and ldconfig, as well as searching the Kylix media for the 6.0.0 version, but all to no avail. With no more time to spare before deadline, I surrendered, but I still hope to make this work soon.
By the way, Kylix does support multi-threaded programming, though many of the built-in objects are not guaranteed to be thread safe. There is a simple semaphore mechanism provided by a globally-declared object which serializes access to any of the GUI objects. In this regard, Kylix and Object Pascal fall short of what I have come to expect from Java, but the business-type applications for which Kylix is intended probably do not require robust thread management. As with anything else, it is up to the programmer to decide what tool is right for the job at hand.
The Acid Test: Putting the Manual Away
As a final test before writing this review article, I wanted to push myself to the limit, to see just how usable Kylix could be after a modest (two days, roughly) learning period.
As an exercise, I decided to try to modify the Text Editor application from the tutorial to also be a primitive web client. I hardwired the URL for a page on LinuxToday into a couple of string constants and then I put down the manual, vowing to admit defeat or savor victory without opening it or the online help. The goal was to have the text editor support a web download button that would fetch the raw HTML (without rendering) from LinuxToday and paste it into the text buffer.
Getting the HTTP connection object into the code was trivial -- it appears on one of the IDE menus, and I simply added it to the main form. It took some dithering around before I remembered that I needed an Action List item before I could create a menu entry that caused the HTTP object to do something. From that point on, though, the process was very simple as far as the GUI was concerned. Within about fifteen minutes I had a menu item and a toolbar button that were intended to activate the web download.
Adding the actual event handler was a little trickier. I could use the IDE to get to the right spot in the Pascal code, where execution control would transfer when the button was pressed by the user, but I didn't know the name of the method (function) to invoke on the HTTP object to make it actually do something. I kept looking in the properties dialog for a "URL" but all I found was the host name. Finally, I guessed that the HTTP method might begin with the word "Get" so I created a reference to the HTTP object and then let the online syntax completion tool list all the "Get" methods for me. Bingo! The method is called, simply enough, "Get()" and its parameter is the rest of the URL not including the host name. Five minutes later, I clicked on the download button and saw LinuxToday's HTML code in my text buffer. Success!
Some might argue, with considerable merit, that this was not a realistic test. Real programmers don't arbitrarily abjure themselves against using the manuals, and two days is hardly enough time to learn a complex development tool like Kylix. Granted, on both points. My intention with this exercise was to simulate a harder problem, but approached after more training with the Kylix environment, and this seemed a reasonable approximation. Likewise, although real programmers don't arbitrarily constrain themselves from the manuals, there are times when one is working from a laptop at a remote location and the manual may be five hundred kilometers away. Even if the manual is at hand, one doesn't want to have to open it every two minutes, either.
So, take this test with the skepticism that is its due. It does seem to indicate that
Kylix is a learnable environment, and by that I mean, "learnable within a reasonable
length of time."