[Lazarus] Please define "delphi compatibility"

[Juha Manninen]

On Thu, Oct 11, 2012 at 10:15 AM, Chavoux Luyt <chavoux at gmail.com> wrote:
> I think we might be getting slightly off-track. Am I right in saying that
> the consensus seems to be that Delphi compatibility is basically one-way?
> I.e. from Delphi to Lazarus, but not necessarily the other way round? If we
> make extensions to the the IDE that does not exist in Delphi, I can see no
> other option.

Extensions in the IDE don't affect portability. The IDE is already
much better than Delphi 7 which was the original goal.
Some parts (like CodeTools functionality) are better than the
equivalent thing in latest Delphi XE3.

Changes in LCL and other libraries do affect portability.
However, the extended features prevent moving the code back to Delphi
only if you use them. It is up to the user to decide if he wants to
use them.

In practice a big GUI oriented Lazarus/LCL application is already
difficult to move back to Delphi.
You must maintain separate form files (.dfm and .lfm) because of
differences in properties. In .pas files you can use IFDEFs but not in
form files.
LCL has been extended already since a long time. Using those
extensions has prevented moving the code back to Delphi. It is not a
new thing.

My personal view is that LCL will be (and must be) extended still more
in future. It means the 2-way conversion of GUI applications will be
more difficult. But, does it really matter? Delphi itself has moved
from VCL to a more modern design, FireMonkey.
Lazarus project must innovate, too. Only imitating a 10+ year old
Delphi 7 is a dead end.


> The only alternative I can think of is if we keep for example a "Delphi
> compatible" TDBNavigator without the ImageList that can be used by those who
> want to be able to port their Lazarus project to Delphi. (So we might have a
> "Delphi compatible" tab for those components where the default Lazarus
> components have been improved/extended in ways that cannot be ported back to
> Delphi. (Or alternatively put all the "extended" components in their own tab
> instead). Is this worth the while?

The TDBNavigator will be Delphi compatible if you don't use the new
ImageList feature. That is the whole point. The functionality is
extended, not broken.

Different tabs for extended components does not make sense.
Instead, the new property that extends a component could be marked somehow.
But again, which Delphi version should you compare with? LCL already
has many properties from later Delphi versions (later than Delphi 7).
I think this would be a swamp to implement. It may be better if the
user reads documentation and tests the compatibility himself.


Regards,
Juha