[Lazarus] THelpEvent declaration discussion

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

>> FPC imports more oddities from Delphi, like the new change of Inc()
> 
> That broke my code too, but if it fixes some odd cases or ambiguous
> code, I'm all for it. It was quick to fix my code anyway.

Breaking changes are not desireable at all, without an option to disable 
them. Delphi has already forked into incompatible Ansi and Unicode 
versions, which require to retain an Ansi compiler, IDE and RTL/VCL for 
the maintenance of legacy projects. FPC and Lazarus should not follow 
that bad example, since it would restrict the use of newer target 
platforms to the use of the new semantics - an idiocy par excellance :-(

In the IDE (both Delphi and Lazarus) it would bind the use of new 
features (refactoring, widgetsets...) to the new *semantics of the 
programming language*! But while the Delphi IDE is bound to an specific 
compiler version, in Lazarus it's at least possible to specify an older 
FPC version for legacy projects. This feature would be broken when the 
LCL has to be modified for any idiocy of newer compiler versions :-(


>> the Delphi VCL and RTL interfaces, I'd wait for Delphi "X" before
>> changing anything, or for the death of Delphi, whatever happens
> 
> That's like saying FPC cannot evolve without Delphi.

I really wonder what's the reason for the breaking modification of 
property handling - if not Delphi compatibility.

> That should never
> be the case! FPC is a product on it's own - delphi compatibility should
> be a "nice to have".

And that's why a *compiler* should not define new standards! A language 
can evolve, and new front-ends can be added to an compiler, but the 
other parts of an compiler should not depend on changes to the 
front-ends (languages).


> Look what happened to Borland when they trying to
> wait and see what .NET or Visual Studio does before they support those
> features. Always playing "catch-up" is a recipe for disaster and you
> will ALWAYS be second best.

The dominance of Borland, in the development system area, has been 
broken many years ago. Since that time it's a stupid idea to invent new 
wheels, because they will be broken by the market leader very soon. The 
Delphi language could have been made more popular by providing a VS 
plugin - as has been done by RemObjects. This product has survived as 
Prism, while Delphi.NET had to be trashed very soon.

As mentioned some time ago, CodeGear and FPC/Lazarus could cooperate 
very well, and together they could place alternative multi-platform 
development systems, that could stand against VS and .NET. Delphi could 
adopt the widgetsets and LCL from Lazarus, and the cross-platform and 64 
bit compiler from FPC, while FPC and Lazarus could use the Delphi help 
contents, and could continue to set new standards and offer native 
development systems (IDE) for all supported platforms at the same time. 
Otherwise CodeGear will have to spend some more money on the development 
of their own compilers, what IMO will result in the next - and possibly 
final - financial desaster.

Another interesting product with little competition were the support of 
Modula and Oberon (like) languages by the FPC. Based on the same (FPC) 
compiler it would be possible to write multi-language projects, like 
it's possible with .NET. IMO this is the way how breaking language 
features could be added, and the well known problems with the stone-age 
Pascal language could be cured, instead of resulting in endless debates 
over source code formatting and other fruitless "innovations".

DoDi