[Lazarus] Please define "delphi compatibility"
avishai.gore at gmail.com
Thu Oct 11 17:10:53 CEST 2012
I agree with Juha on this. Chaining Lazarus to 2 way comparability
with any version of Delphi is placing an artificial limitation on
Lazarus that should not be there. Even Delphi is suffering from
backward compatibility issues. That Delphi should be a starting point
for Lazarus is obvious, but to say that Lazarus can never be more than
Delphi is a horrible idea. The last version of Delphi that I used
(D6) made Globalization virtually impossible. Lazarus is a global
community and needs to address this even if it means making
compatibility a one-way process.
On Thu, Oct 11, 2012 at 4:46 PM, Juha Manninen
<juha.manninen62 at gmail.com> wrote:
> 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.
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
avishai.gore at gmail.com
More information about the Lazarus