Re: Captain Jake's Top Ten List of what I'd like to see in thenextversionofDelphi


"Allen Bauer" <abauer@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44a55bab$1@xxxxxxxxxxxxxxxxxxxxxxxxx
As it happens, its been possible to recompile many 3rd Party D7
components
in D2006, as is. This is because there have been almost no changes
between
the native VCL/Compiler between D7 and D2006. A good thing? Not really.
I
don't use Delphi because of the IDE, this is a minor consideration for
me;
and I found the D7 classic IDE to suit me just fine. Significant
improvements/upgrades to the native compiler and vcl architecture would
interest me a whole lot more.

Uh.. let me get this straight... You're saying that because some code
didn't break that must mean that very few changes were made to VCL? I was
always under the impression that folks *liked* it when we do a lot of
changes and their source still compiles with no changes. So in this case
I think we succeeded very well since there *was* a significant number of
VCL changes from the core all the way out to the individual controls. Now
that we have things like function overloading, default parameters, and
other nice language features, the likelyhood of breaking source in the
future is significanly reduced even more than before we had those language
features. I'd say we're moving in the right direction here.


This may be the case, as you say. I've never complained about the price of
change. If I needed to tweak my components to get them to compile in the
next *improved* version of the compiler, I never saw this as a bad thing.

I hear what you are saying vis a vis D7 to D2006 changes; and I am glad to
hear it.. But, If you are saying that you will never need to make changes
to the the compiler that impact existing VCL code, because you have
implemented the needed insulation in the architecture then I'll need to see
a little more time pass (versions released) to verify that. For instance, I
anticipate significant tweaks to my code wth the 64-bit compiler and VCL.
If you are saying this won't be that case, then my hats off to you.

What this tells me is that the Compiler/VCL is truly becoming portable, and
perhaps we could see another stab at the Linux market in my life time....

-d



.

Relevant Pages

  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... If you are saying that you will never need to make changes ... to the the compiler that impact existing VCL code, ... compiler and VCL. ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... If you are saying that you will never need to make ... changes to the the compiler that impact existing VCL code, ... compiler and VCL. ...
    (borland.public.delphi.non-technical)
  • Re: Win32 Needs
    ... But you'll need more than the compiler if you want to compile 9x ... You'll need the RTL, the VCL and such. ... platforms the IDE is supposed to work on, to see if say a new windows ... I'm not saying it's impossible, I'm not saying it can't be done. ...
    (borland.public.delphi.non-technical)
  • Re: Whats the big deal with cross-platform?
    ... VCL is performant and native, you really don't want to say MFC is superior, do you? ... Almost every alternative framework takes similar approaches to the VCL, that hardly is because people think it is a bad idea. ... MFC can also be ported to other C++ compilers if the vendor wants to ... VCL requires you to use Borland's compiler, ...
    (borland.public.delphi.non-technical)
  • Re: Is it possible to cancel a destruction ?
    ... Well compiling the VCL was quite simple but required a little bit of work. ... the VCL and then the compiler would simply use the VCL sources to build the ... The compiler was unable to find the resource files. ... delete such a folder without even thinking about it another further. ...
    (alt.comp.lang.borland-delphi)