> With all respect, but the code samples presented are really examples of > bad > coding. Personally I wouldn't expect this kind of code to survive such a > transition.
While again not my code and in 3rd party components, I think you will find a large number of 3rd party components that are older are written in a similar way. Also while I think it could be written better, I wouldn't consider it bad. Code works, is fairly fast and readable. Changing SizeOf was the problem in the first and StrPas while out-dated was a necessary evil for a long time and most components we use date back to Delphi 1. They have been upgraded along the way, but older code that works still remains. Switching between AnsiString and String in definitions is bad though. I would also point out that code was from a fairly well known 3rd party component package. I won't name names, but I know several companies that continue to use their products. >>True, but the boss sees a port as necessary at some point. So long as we >>keep the product patched and low maintenance there isn't any justification >>to move it. > > In that case you might as well keep your old Delphi version on your > system. That is on the table, but getting to x64 would be a big selling point to our customers as our middle tier servers could actually take great advantage of it. This is a step in that direction. We could maintain our servers in 2009 (or whatever the next Delphi is with x64 support) and client in 2007, but that would be a PIA and a difficult sell to management. Plus I am not sure how our middle tier would react to having client side "String" routines work one way and server side work another. We could cast everything going out server side as AnsiString but another PIA. Oh and the middle tier is an easy Delphi upgrade since all the code there is very generic. >>However, we deal with a lot of encryption, compression and >>multi-platform code > > C# is no option with multi-platform code. You would be wrong there. I have written several apps in C# using mono that work great. Besides, the code I am referencing doesn't need to be multi-platform for us but was written that way to handle data from other OSes. We only use the Win code, but the other OS considerations in the code couldn't be easily uncoupled. Besides, we have been waiting for some time to have a window to upgrade as we don't get many lulls in our workload to perform these types of upgrades and testing. Since it will probably be another couple years before we can pull off an upgrade of this scale, C# has to be considered and we would be fools not to. > I realize your problems are a lot more > varied, but if you switch to C# you're going to have to re-purchase all > your > components anyway! We already have most the components and licenses since our shop does work in C#. Until now C# has been limited to HTTP based front ends and some back end services. This really wouldn't be that difficult for us, C# already talks to our Delphi middle tier (the real bear to rewrite since all the business logic is there). It would take a lot longer for us to port the client, but our client that uses these components is UI only and some utility code that handles various file inputs. > It's a matter of money for time or money for purchase, > and if you can simply hold on for a year, porting only those components > you > must, the third-party vendors are going to have to update their offerings > anyway. Whether we port a component or buy it makes no difference to them financially since both cost money. Also, we have a lot of components that simply aren't in business any longer. Granted it would be best to get off those components (Jasmine, XDom, ImageLib and some others) but in some cases the change is as drastic as writing all new code. The big minus for Delphi is that any changes look to management as money wasted which makes getting funding for these projects difficult. If we put the same effort and money into C#, it is a pretty easy sell. To date, putting money into Delphi projects has been an easy sell since it wasn't time consuming and thus low on cost. This port changes that dynamic. > Besides, C# is so dam ugly! Won't argue there AT ALL. I actually loath C# but it is the industry mainstream these days. For us we get a window to make big product upgrades every few years. If we wait now, it will be 2-3 years down the road before we have the option to do this again. I am leaning towards leaving it alone since it is easily turning into a big job that would prevent us from doing another project we were planning in the same window. I think if we decide to upgrade, it will be C# on the front end which means the next big upgrade would be ditching Delphi completely with a middle tier rewrite. All this over a string. Reminds me of the D1 to D3 and the CLX upgrades we went through. __________________________________________________ Delphi-Talk mailing list -> Delphi-Talk@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
