Having read this thread with interest, I feel compelled to say something. Very simply put, I have no care how good a piece of code is by any other judgement. If it cannot be ported, it has already failed the most crucial test for code. Okay, maybe that is a bit harsh, there are obviously exceptions (nobody expects you to write a platform independant network device driver) and if you stick too religiously to this, then you deny developers the opurtunity to ever make use of platform specific features.
However, if what you are depending on is in fact a platform specific bug, easter egg, undocumented feature, kludge or limitation then frankly your code has lost all interest. Doom was a great game, but all the greater because it scale from the single user dos world to the multi-user linux world without exploding. We are entering a world where the amount of platforms are increasing, maybe right now most software companies haven't noticed yet, but how long can they ignore the incessent growth of other platforms and be economically viable ? I first started using FPC in the very early days because it offered a TP compatible compiler on Linux, and those of you who knew me from then will remember the dos kludges of my code at the time. I stuck with FPC (including trying in my own ways to contribute) because it was multiplatform. It takes time to learn how to code platform independantly to the greatest degree. But it is a skill that I think will become a vital job requirement for all developers in less than 5 years. You can either stuff yourself up with java - or use a decent cross-platform compiler, and just code a little smarter (seems like a nobrainer to me). Having said all this, I think Lukas has written a really good piece of code in synapse, and I am glad about the fpc port. But Lukas, fpc is not intended to be a free replacement for borland, or a linux clone of tp or delphi. It is so much more than that, and if you code for it or in it, it is a deffinite advantage to never forget that. A.J. On Thu, 2003-07-24 at 09:38, Michael Van Canneyt wrote: > On Thu, 24 Jul 2003, Lukas Gebauer wrote: > > > > That isn't. I was more hinting at the TSystemTime example. Sysutils is > > > platform independant, and Windows is dependant. > > > > Ok, enhance this my example: What is different between TSystemTme > > structure in sysutils and in windows? Windows structure have only one > > additional field 'DayOfWeak'! > > > > Why platform independent implementation in FPC sysutils not have this > > field? Simply add this field to FPC sysutils and then you have two > > compatible structures. What is platform depended on 'DayOfWeek'? Why > > is not here this field? > > > > Core of this problems is not platform independency. Or not? > > In this particular example, the field was simply forgotton, and we'll > add it. This is not a problem. > > > For example, dynlibs. Same functions is in Borland sysutils. (for > > both, delphi and Kylix). But in FPC it is in separate unit, and one > > function have different name. (I mean UnloadLibrary instead > > FreeLibrary) > > Simple: > Our unit was implemented first, and the Borland unit appeared later ! > > > > > Why is impossible put into your sysutils same functons as in Borland > > and this new functions will internally call dynlibs unit? If some > > platform not support dynlibs, then simply not add this functions into > > sysutils on this platform. > > 1. We will add them in the main branch, just as you say, they will call > the implementation in dynlibs, and will be Borland compatible. > > 2. They will raise an exception if not implemented on a specific > platform. Otherwise users will still need IFDEFS anyway. > > Michael. > > > _______________________________________________ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Do not try to think outside the box. That's impossible. Instead only try to realise the truth....There is no box. A.J. Venter Tech Guru DireqLearn. _______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
