I have a very big server project, working fine in Delphi and plan to test how it will work on font net core, plus take advantage of others available platforms on net core.
I try in the past, and fail.
Why? because the only way to make it happen is sharing Delphi base code with net core. Theres no other chances it happens with a live project like this, to have to codebases or a lot of ifdef inside that codebase.
Im crazy? Is impossible to share codebase between Delphi and Oxygene? Maybe don’t. Maybe some simple adjustments in oxygene can do the big difference. I only knows is impractical to try this in the way the things are in this moment.
So, Im trying to do constructive suggestions to make easiest to taje that trip. I know many of that hit the
ideal scenario when working on oxygene language. Please consider that:
All the suggested adjustments are only for a full compatibility with Delphi and maybe not the ideal for the
Oxygene language daily usage. The point is , remember, make easiest share server code between Delphi and oxygene.
Let me explain that in detail.
We need class aliases to translate some Delphi classes (DA classes and RO classes, mostly) to dot net classes. See data modules ahead.
We also need units aliases to translate some Delphi units (DA classes and RO classes, mostly) to dot net classes. Remember : the idea is don’t touch Delphi code at all.
Units vs namespace.
Must I modify 2000 files , put an ifdef at the top to use the word namespace vs unit? Why not better in Delphi compatibility mode Oxygene recognizes that word and understand is another namespace? Every Delphi unit have a uses clauses referencing that namespaces. In Delphi compatibility mode is ideal allow to uses units as the first word in pascal unit.
Any Delphi servers have a lot of data modules. How to solve that with oxygene?
I think in a dfm to code automatic generator, and an initialization function (to put a name) called in the datamodule source file to generate all the classes needed, in case compiler is oxygene.
Stuff like freeandnil must be supported on Delphi compatibility unit on oxygene. I have no idea if that is supported right now. I believe you already do an impressive work there.
General usage of DA and RO
Must be analyzed how to accept code like this in DA dot net version.
var lConnection : IDAConnection; lQuery : IDADataset; dw : TDAWhereBuilder; begin try lConnection := ServerDataModule.ConnectionManager.NewConnection(fDBConexion); if not lConnection.InTransaction then lConnection.BeginTransaction; lQuery := SchemaGetDataset(lConnection, ServerDataModule.Schema, 'TABLA'); dw := lQuery.DynamicWhere; dw.Expression := dw.NewBinaryExpression('', 'IDTABLA', dboEqual, 100); lQuery.Active := True; result := lQuery.FieldByName('NAME').AsString; if lConnection.InTransaction then lConnection.CommitTransaction; except on e:exception do begin if lConnection.InTransaction then lConnection.RollbackTransaction; Log(' procedure X Error ' + e.Message) end; end; end;
@antonk tell me in the past that code is very old fashioned. Maybe. I don’t know, but comparing the code in dot net you put… is fair more readable… And as it use interfaces is fair more simplest to release, by example, the connection.
In any case must be an equivalent way for each call to allow share the actual valid code in dot net.
Autogenerated RO DA intf files
AFAIK that is already compatible, must recheck how it works in my last try.
Delphi dpr file compatibility
A big plus, only RO team can evaluate if is possible.
I will adding to this list if something more comes to mi mind. But that items are the big stones to jump to start.
my .2 cents.