Hi folks,
Prof A Olowofoyeku (The African Chief) wrote:
This has been an interesting debate, but I fail to see the point of prolonging it. What has been raised is a fundamental question about whether and to what extent GPC should aim for Delphi compatibility. On that question the silence of other members of this list has been deafening. I can only assume that this is because no-one else is interested in Delphi compatibility. If so, then it renders any debate moot. If not, then it would be good to hear what others think.
I think, a verbatim Delphi compatibility of GPC is _not_ a good idea, especially regarding its tendency to C resemblance, which was the trigger of this thread. In my experience, the Delphi tendence of imitating C leads to nothing but making Delphi a _less_ powerful language. (E.g. the Delphi _styleguide_ -- not even the compiler itself -- tells you to put every class definition into a file of its own, thus yielding lots of cross-reference errors whenever two classes have to know each other. A "true Delphi developer" will rather implement dozens of f*cking workarounds than break with this C-style rule.) Adding procedure calls with empty parameters lists would increase confusion in GPC without enhancing its abilities.
Delphi compatibility of GPC should be restricted to the effort to provide all mechanisms Delphi is capable of, but not necessarily with the same syntax. E.g. there should be an exception handling mechanism with try..except..finally clauses, but they needn't exactly look like their equivalent in Delphi. (Remark: Sorry, Frank, I still haven't had the time to look the mechanism up in the GCC backend.) Since we already have parameterless procedures, we need no second mechanism for the same use.
Yours,
Markus