Peter Popov wrote: > > Yes. Failure of Delphi users to have any consensus about what is compiler > > behaviour, and what is language behaviour. Every bit of behaviour that > > Delphi exposes is considered gospel. > > That is true and is compounded by the fact that there is no ISO standard.
It's significance must not be overrated. See the relative incompat of older MSVC++ compilers. > > victim > > to its own assumptions because it had to deliver a way smoother > > transition, which failed in a still to volatile delphi world. > > I don't know if borland targeted the "recompilation market" or new linux > developpers. I think so. > If they wanted the recompilation market they should have single sourced > the VCL. I guess that was not possible without compromising their main moneymaker. > They should have released a reasonably bug-free multiplatform > VCL. They should have priced it much cheaper and integrated the compiler > into the win32 ide for cross-compiling and so on. It is actually useful to > study why they failed. I think that is revisionism ( also a problem in Simon's article). At that time the Linux hype was at its peak, and navigating the dangers of being stoned to death by the Linux opinion makers was a top priority. ALSO crosscompilation maybe. But only crosscompilation was marketing wise not doable I think. >Kylix is certainly dead, but finding out why will help others... Some > interesting views can be found here: > > http://delphiroadmap.untergrund.net/A_cross-platform_vision_for_Delphi/index.html I know the article. I've commented extensively on it when it came out in the relevant Borland groups. > developpers. On the other hand, say any stable fpc release should be able > to compile (on win32), without trouble the entire VCL of say, delphi 2-5. I don't see why that is a focus point. It's a nice testsuite, but until it is free, there is no real benefit in it. Specially since the VCL-RTL separation is not complete, and neither is the compiler - RTL separation. > - I've had recurring problems with open arrays on various final releases. > Some issues were fixed by the developpers, for other there was no > agreement what the language standard should be so I had to make > workarounds Yes. I assume that was the cdecl one? Since nearly any standard doesn't cover much details about external linking, and general link and calling conventions issues, I doubt a language standard would make this go away. THe other one was fixed. > Also, it is not clear if functions with open arrays can be > exported/imported safely in dlls, as I don't know what is the internal > representation of an open array in FPC. I'd guess it is safe for fully static types, and not safe for types allocating memory. So ansistrings and dynarrays, no. > - Static linking requires some minor code modifications in comparison to > kylix (they had their internal linker, so things can't be the same) (some were fixed for CrossFPC) > - Minor issues in the FPC RTL force various workarounds. E.g. > http://www.freepascal.org/mantis/view.php?id=8578 This is unavoidable, without freezing the scope of the project to produce a minimal clone. I do a lot of porting (Jcl, Indy, ICS, Decal among others), and while such issues are constantly discovered and fixed, the ones that stay like this are extremely rare. > - Various features that use the internal RTTI of delphi. For example > delphi 2 generates useful RTTI for automated methods, Delphi 6 for > published method (in conjunction with a weird compiler directive). Clearly > this is not a language feature, so one cannot insist the FPC should do > things the same way. Unfortunately, currently this is a blocking issue for > me. Yes. The problem in this case is clear. Automated is deprecated and rarely used functionality. (like e.g. dynamic methods). > >> A final remark: the vast majority of pascal users use Delphi. So if fpc > >> is > >> to attract a lot of them, compatibility with delphi must be 100%. > > > > These kinds of claims always promise heaps of users, but there are > > several problems with it: > > - Only a fraction of users will defect to run a clone. > > True, but the delphi crowd is (well, still is) large. So a small fraction > is not bad at all. Keep in mind that the actual project success is not measured in numbers. We don't get anything per download, we are "paid" in project activity and bugreports and patches. A higher focus on compability would hurt badly in other area's that do deliver "pay". And since the bulk of the users you pull in with such an extreme (and costly) focus on compat is of the low pay kind.. > Besides it is not only about defecting. What if FPC is available as > cross-compiler inegrated in Borland's windows IDE? Do you ever see that happen in a scale that matters? > Personally I can see > FPC server applications running on a bizarre patform and a client side > compiled with delphi. Oh, sure. But I don't think that that will shift the balance in any way. > > - The compability is never enough. > Well, as long as there are no blocking features and no necessity for > too-many workarounds/$IFDEFs people will accept it. Talking in extremes is too easy here. My point is that everybody accepts something that is perfect. But how close to perfect is perfect? Specially when the bulk of the people are only trying to get a free ride (get their product compiled one or two years longer, or a free other OS port). Keep in mind that we already were in such a spot with TP/BP. No mass migration started because it was all not ready when BP was somewhat alive, and when the extinction started, most jumped ship to Delphi or VB, and only tried to cheaply get their old projects (in which they didn't invest anymore) running. This is also why I wish Delphi/native a long and prosperous life. We now also get a certain percentage of users, and a fairly skilled and willing to invest kind. If Delphi would die, this would end, and the wave of publicity that the demise would cause would only yield a larger percentage doing superficial and dumb attempts at braindead recompilation (which give you a bad name for years), hardly yielding any new users in the longer term. > Alternatively, someone should define a language standard. Actually I don't think it would change much. Simply because the existing codebases on Delphi wouldn't change by it. It would be like the existing pascal standards and the object pascal draft standard. Moreover, considering the stuff you describe (shared linking, external linking, calling conventions, OS specific modifiers like automated), this is generally not the stuff guaranteed ins standards. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
