[fpc-pascal]Synapse for FPC
ajventer at direqlearn.org
Thu Jul 24 21:42:50 CEST 2003
Having read this thread with interest, I feel compelled to say
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
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.
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)
> 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.
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
Do not try to think outside the box. That's impossible.
Instead only try to realise the truth....There is no box.
More information about the fpc-pascal