[lazarus] Delphi and FPC compatible LCL version

[Andrew Johnson]

wow I seem to have missed all the fun. :)

well here is my long winded take on the subject(not to reopen the
issue). 

1.) Why should it be ported to Delphi? 
   well several answers here mentioned, 
	a.) another compiler to test and find errors with
	b.) closer compatibility with vcl. 
	c.) larger programming community
	d.) well, why not its Open Source, anything should go. 

these are not bad reasons and not entirely incompatible with the goals
of LCL and lazarus assuming they are true/work out this way. But that
brings up the next subject, why not? why _shouldn't_ we accept this sort
of patch? 

2.) Why shouldn't it be ported to Delphi
 I have heard and have several reasons I have my own where I can see why
not -
	a.) The LCL is an FPC project, more specifically -

		if the LCL is a FPC project it should take
 		advantage as much as possible of the programming
 		advantages offered by FPC, in my opinion not only
 		should the LCL and lazarus sources use ObjFPC as
 		much as possible, they should make use of the
 		extensions offered by FPC where it makes for more
 		readable code, and where it makes for easier
 		maintenance etc. 

		Eg is in the GraphMath unit I
 		made use of operator overloading to simplify bezier
 		math. this is not only more readable code, it is 		less then 1/4'th
of the size required in Delphi. 		properly ported to Delphi not only
ensures a larger
 		code-base but less understandable code, if this
 		project were always intended to work with both
 		making this sort of sacrifice would make sense, but
 		it was not and has not, and converting to Delphi
 		means a step backward for something not even part
 		of the intended goals.

	b.) porting to Delphi does _not_ ensure better VCL compatibility

		Porting to Delphi means only a few things, the LCL
		now works with Delphi so long as you do not use the
 		VCL at all, or change the names of all the LCL to
 		be incompatible with VCL names so they don't
 		conflict. 

		If we wish LCL to work with Delphi properly we must
 		change the names, to those like in kylix, so not
 		compatible, and either do this only for the Delphi
 		version, which means FPC LCL and Delphi LCL apps
 		are not source compatible without ifdefs etc., or
 		for all apps, which means old LCL apps need to be
 		changed, and Delphi VCL apps _still_ need more
 		modifications just of files, not to mention all
 		controls and back-end differences ensured by the
 		very cross-platform nature of it. Both solutions 		break the very
concept of LCL portability.

	c.) maintainability
		if changes are kept within ifdef's this adds huge
		overhead to the complexity of code, if it were
		stored in includes, then due to the nature of the
		current layout whole files will need to be
 		duplicated for minor changes, either case adding a
 		great deal of problems to maintainability
 		especially to those who currently work and develop
 		Lazarus and the LCL, but have no interest in the
 		Delphi port for themselves, 

		So either the current developers must also
 		maintain this additional code meaning less 
		time for overall development, or they must leave it 		to other
people	to upkeep, which in an open source 		environment is not assured,
and given the large 		amount of code currently in the LCL, it might be
		months between times LCL even would compile with 		Delphi anyway.

 		Basically IMO, meaning such a port cannot be very 		official, or
supported, which for the most part 		seems a waste of time and space for
the project at 		hand.

Basically I think the overall complexity and problems caused outweigh
any small benefit gained from it. If this is wanted it should be
maintained by those who want it, as a set of patches against the LCL. I
am not against people doing this, and maybe in the process finding
non-compiler specific bugs, or minor inconsistencies which don't affect
good FPC compatibility that can be committed directly to CVS, but the
bulk of the changes suggested are not worth it and will cause far to
many headaches long term to do much good as part of the LCL, however as
kept as a separate set of patches, against specific versions or dates of
CVS, it ensures those who desire this, can get it and know it should
work with specific versions.

there is more, but I think thats a good enough set of reasons why not - 
inability to take advantage of most of the improvements FPC has to
offer, complex, harder to maintain, breaks consistency between apps,
makes porting harder.

when it comes down to it the problem should be easy porting of Delphi
apps to Lazarus. Due to various issues they _cannot_ be fully
compatible, and moreover, often times (for instance lfm/lrs vs dfm)
cannot be shared, so even when a project is intended to be shared, much
code cannot be, trying to make as much as is possible shared is good,
but easy porting should be more important. if all the important feature
sets are available, and wizards and guides are available to simplify the
process, porting should be rapid and easy, even if the LCL is say only
75% compatible.

Lazarus to Delphi porting doesn't make a whole lot of sense imo, we are
working on an alternate IDE and backend, not a clone I don't like
everything in Delphi or the VCL, many things I would prefer done
differently, should we make Lazarus and the LCL compatible just for
compatiblities sake? I am more prone to lean toward compatiblity but not
if/when we can do it better. So it shouldn't be the focus, and when
patches to make more compatible don't conflict or make more complex
things better done other ways, great, and apart from win32 specific
stuff, there is no reason that if ways were found we couldn't get and
stay 90% compatible, but it shouldn't be the main goal, the portability,
ease of use, stability, and total available feature sets should be.

Frankly, even all Delphi's are not compatible with each other. Delphi 1
Delphi2 Delphi3 Delphi 4 Delphi 5 Delphi 6 Delphi 7. NONE of them are
fully backward compatible, just mostly. A delphi 7 app can be made to
work with Delphi 6 with porting, but porting back further becomes more
and more complex to where porting to D1 is ludicrous at best. Should
lazarus be 100% compatible with all versions when even they aren't? When
the LCL can improve over D7 or earlier or whatever, for the most part it
should, but compatibility just for compatibility sake should never be
the driving reason behind the LCL.

end ramble/rant :) 

Andrew

On Sat, 2003-11-15 at 19:48, Florian Klaempfl wrote:
> Yes, I know. But: Delphi compatibility could bring the lcl to a broader 
> audience and at least for Kylix developers the lcl is usefull to write 
> GTK applications. Further, a broader audience could also gather new 
> developers for the lcl. My personal opinion is that an open source 
> projects should accept all patches if they aren't too strange. Of 
> course, nobody expects that the current lazarus developers spent time 
> into keeping the lcl compilable with Delphi/Kylix. But if somebody 
> provides patches why not incooperating them?
> 
> Just an example: sometime ago, someone contributed patches to compile 
> FPC (the compiler itself) with Delphi5. This is pretty useless because 
> Delphi often IEs when compiling FPC or creates a non working FPC. If the 
> created FPC works, it's two times slower than an FPC compiled with FPC. 
> Nevertheless, we applied these patches. Why? Well, it's the way how OSS 
> development works. If a patch affects core functionality of a project, 
> it's another story but it doesn't seem to be the case here.
> 
> Of course, finally it's your decision, but just my 2 (euro) cent ;)