> Because strings already existed in TP. > Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils.
You only therfore need sysutils, *or* the old scheme. Not both. I understand why this was done by Borland. Legacy is hard to break, and D1 broke with legacy. > > You don't follow the Borland one. This is therefre your own scheme. A mix > > between Delphi and TP. > > We _do_ follow Borland's one, just they have two schemes, separated in time. > > We also have two schemes, but not separated in time. And therefore your own scheme. It's not the current, nor the old, but a hybrid on the Windows platform, and on the Linux/BSD platform I expect you *do* have some of your own scheme in place, I have never looked. > > LOL!!! I've been using Delphi since v1. This is a complete exageration. > > Between D2 and D5 the unit changes are minor. > > Have a look at db.pas. The truth is, I have ported extermely large apps from D1 to Delphi 3 and 4. There is no significant problem, so long as you didn't do nasty hacky things with the implementation of TTable etc. Class hierarchies have changed, but this should and does not matter. The code, so long as it does not break any rules, still compiles. D1 was the biggest DB change, and D1 apps are fairly trivial to convert to D3, so long as you respect the language features that have changed. From D2 to D5 is pretty straight froward too. > This is not 'minor'. e.g. all code setting these 'new' properties would have > to be removed. For a small demo app, this is unlikely to happen, but in > a large project with about 126.000 lines of implementation code, it can > be painstaking... The IDE will remove all unknown properties from the DFM when streaming it in. The rest is accademical. Most properties that have been introduced are to do with support for unicode and bidirectional languages. Borland are very good at not adding nasty additional features. It's thrid parties that usually excel at that. > But I agree that Borland tries to keep backward compatible. And rightly > so. If you mainly use native Borland VCL components, the transistion from D2 to D5 is fairly trivial. The migration from D7 back to D5 is also trivial, although you will run into incompatibilities due to language features that have been added (the new $if and enum types that allow indexes to be specified being two that crop up frequently.) I've ported Dave Jewels GDI+ examples from the Delphi Magazine to Delphi 5, and he uses just about every new feature he can find. That was pretty trivial. > This is highly a matter of taste and preference. > > > Explicit overloading is an example of this. The only thing I see FPC > > has over Delphi still, is operator overloading. Even then I wonder if I > > really need that feature. > > You don't need overloading either, just as you don't need exceptions and > classes and interfaces. This is a matter of taste... Sure. Overloading should be used sparingly (as James Mills proved last week.) Exceptions are needed. Classes are needed. Interfaces are usefull. Not my taste, just a fact. They are too well established not to argue on. > Maybe so, but there are still a lot of old projects or code snippets > that people made, and which can be compiled with FPC to be reused again. Any many more that do not work due to the flat 32bit memory architecture. That's a bit like saying "I can use COBOL.Net to compile my old mainframe apps for Windows." Maybe even like saying "I can recompile my old VB6 apps in VB.Net." ;-) > The number of times that I get a message from someone thanking us that > we keep fpc compiling TP code e.g. on linux is more than enough > justification for keeping the different modes and language options. Sure. But you could create a 'TP' branch of the compiler, remove it from the main compiler soure tree and leave it for the legacy peeps. If you got the seperation right, you could still share sections of the engine, just not the code parser and such. This would then focus FPC on the here and now, and you could remove the legacy from the unit tree. > But rest assured, I don't program TP code, I program Delphi code, as I > think it is more 'right'. You got my vote ;-) Matt _______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
