Delphi classes_(re)

Mon, 7 Jul 1997 17:55:36 +0200 (MET DST)

Hello Dave, hello everybody!

According to David Fiddes:
> According to myself (Peter Gerwinski):
> >What Borland did with Delphi was to design the compiler to work
> >together with exactly one library (VCL), exactly one set of development
> >tools (object inspector etc.) on exactly one platform (Windows).  I don't
> >like this approach because it contradicts the general applicability of a
> >compiler.
> 
> NO WAY! The only odd thing about Delphi is the compiler portion.

Sorry, but I don't understand this.  I have the impression that we are
referring to different things when speaking about "Delphi".

Since I think it is important for future GPC development that I understand
what Delphi really is, let me please pose some questions - and sorry, if
they sound stupid.

> The whole
> system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from
> the ground up.

What do you mean with "unlike C/C++, Pascal, etc."?

These are language definitions, which do not say anything about the platform
the compiler and/or the compiled program have to run on.  The only platform-
specific think I find in the language definitions is that all of them require
some terminal I/O for implementation of the `writeln'/`printf'/etc. procedures
/functions.

> The only thing preventing it is that Borland  is too
> skint/not interested in doing it.

Here I agree:  If Borland wished, they could make Delphi platform-independent.
What I meant above is that they decided in a quite early stage to support only
the Windows platform, and now it's way too late to adapt VCL to support, say,
X11 as well.  I would be glad if somebody proved me wrong.

> You can replace the VCL if you so wish
> the only thing you lose is compatibility with the IDE.

This is the point where I must ask:  What you mean with "Delphi"?

So far, I have seen four definitions:

  1. the language definition,

  2. the compiler (including compiler switches and such),

  3. the compiler and the VCL, or

  4. the compiler, the VCL, and development tools (the IDE plus all
     the tools for "visual programming").

When speaking about Delphi compatibility for GPC I refer to meaning
#1 above.  #2 is out of range, but one can work around this by using
(*$ifdef*)s for incompatible compiler switches.  (* There is only one
thing in GPC preventing us from really doing so: the missing {$ifopt x+}.
That's still planned. *)  Most people who want to have a Delphi-com-
patible system mean #4, but could live with #3, too.  What I personally
aim is #1, but I am almost sure that once we have #1, somebody else
will create #3, and perhaps even #4.  :-)

> The Windows VCL
> implementation could quite easily(and I mean this)

Why do you think this would be easy?

I doubt that it is, but (as I already wrote) I would be glad if somebody
proved me wrong.

> be swapped out and
> replaced with an X-Windows-VCL, Mac-VCL, NEXT-VCL, etc,etc,etc.  It should
> be possible to build(as in compile) a standard(i.e.  not using Windows fns
> direct) Delphi application on any compatible compiler/processor/OS
> combination without touching the source at ALL.

You mean the source of the program, not that of VCL.

You are probably right.  The point where we disagree is the "quite easily"
above.  As far as I have understood Delphi's internals up to now (which is
not much, sorry), you need a lot of compiler magic for a working VCL.
(That's what I meant with the compiler being designed to work together
with exactly VCL.)

For example, when I create a Delphi project (Thanks, Larry!) with one form
containing three `CheckBox'es, Delphi considers the following as the source
of my program:


    -- project1.dpr --

    program Project1;

    uses
      Forms,
      Unit1 in 'UNIT1.PAS' {Form1};

    {$R *.RES}

    begin
      Application.CreateForm(TForm1, Form1);
      Application.Run;
    end.


    -- unit1.pas --

    unit Unit1;

    interface

    uses
      SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls,
      Forms, Dialogs, StdCtrls;

    type
      TForm1 = class(TForm)
        CheckBox1: TCheckBox;
        CheckBox2: TCheckBox;
        CheckBox3: TCheckBox;
      private
        { Private declarations }
      public
        { Public declarations }
      end;

    var
      Form1: TForm1;

    implementation

    {$R *.DFM}

    end.


>From this example I can learn that Delphi

  1. allows to pass class types as arguments of procedures somehow
     (see the call to `Application.CreateForm'), and

  2. allows some magic for the other parts of VCL to locate the data
     fields `CheckBox[1-3]' in `TForm1'.  (* Is this the meaning of
     the famous `published'? *)


While I can accept most general-purpose language extensions (#1 could be
such a thing), I don't like compiler functionality specifically designed
for one library - which I suspect in #2.  Please correct me if I am wrong.

> GNU-Delphi is a real
> possibility. The only thing you would lose is the pretty IDE which,
> naturally, remains the property of Borland...afterall, everyone has a
> Windows box to do the initial development on.

(* One of the reasons why I started with GPC was because I cannot
stand Delphi's IDE ... ;*)

Not everyone has one, but everyone who wants to use such a "GNU-Delphi"
probably has.

How should such a GNU-Delphi look like?

> I would be really interested in a command line cross-compiler for Delphi
> that would allow me to port my existing Delphi software to the Mac,

(The Mac is likely to cause trouble here, because MacOS is not supported
by GNU, AFAIK.)

> X Windows,etc for nil effort.

"Nil effort" isn't realistic - at least the compiler switches will have
to be adapted - but let's aim "minimum effort".

> I build educational software for a living
> which gets sold to the general public/consumer(all PC based) and to
> teachers/schools/colleges,etc which for various political reasons use a
> wide variety of muck including Macs....I want to sell to these folk...these
> folk want to buy from me...but they don't want to have to re-equip with
> PCs....

... which I can understand well ...

> and doing serious development on anything other than Delphi is out
> of the question as it would quadruple the lead time/number of staff
> required to complete a given project.

(* For me it's vice-versa:  Using Delphi for serious development would
quarter the time needed to produce a running program (10%), but would
quadruple the time/number of staff required to get it stable (90%). ;*)

> fyi, this is why I like GNU-Pascal.

I hope - and am doing my best - that you won't be disappointed.

> yours (rantingly),

:-)

Yours,

    Peter

 Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
 maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)