Bill Meyer

Linux is free, not Delphi. If people want to pay for Delphi to build software for Linux, let 'em. So long as Delphi Pro is not free, I don't see that it is "work for nothing".

Agreed. However, they are not starting over, and would be unlikely to do so, with the low popularity of Pascal today. Given the inertia in the existing code, and concerns over breaking changes, as well as the lack of deeply committed language heavyweights on development, I think that the trend to cross-platform is likely to continue to dominate. I would like to be proved wrong on that.

Pesky facts. You cannot do what you wish, with the product which exists today. Facts don't yield to attitudes. Hard to say what the future holds, but so long as the pursuit of cross-platform seems to take a high priority, the enhancement of currently functional language elements is unlikely to be reconsidered, IMHO. You asked how to do what you want, and the answer is that you can't. At least not now. We all have our pet wishes for Delphi features, and I think there could be astonishment at how little commonality of opinion there is.

One issue I note with Pascal Expert is that the supported versions begin with D2007 on some pages, and D2009 on others. I noticed because I am still very active in D2007, which FixInsight supports with no problem.

It's less about the number -- though number is a consideration -- than about the thoughtful and deliberate decisions made with regard to extending the language. That said, I dare say we all have our pet topics for improvements we may consider very important. One factor in our assessment of the keywords issue is that we have limited awareness of future plans to extend; we cannot properly assess without more data than we presently have.

Historically, the growth of Delphi has been very spare in introducing new keywords, and that is one of its strengths.

Implementing an override to a virtual method the signatures must match. Your error is not from using override, but from changing the signature.

Use override.

I was keen to get Kylix and thought CLX was a good start. I think what killed Kylix was the plethora of Linux distributions which added twists and turns from Borland's perspective. And for those of us testing the waters, the fact that there were only 3 distributions (if memory serves) on which Kylix was certified to work was daunting. Then there was the lack of components -- how many do anything non-trivial in Delphi without the use of third-party components? And as to components, Delphi 1 offered no component in support of serial ports, at a time when almost anything which connected outside the PC used serial ports. That was remedied soon enough by the appearance of third-party components, but always struck me as evidence of blind spots in determining what the base components needed to be. Further, the component business has always been problematic, as Delphi must ship with components, and realistically must also add to its component sets over time, but then risks competing with the third-party vendors who are essential to Delphi's popularity. I do not imagine in my wildest dreams that Embarcadero will do anything serious with open source. The Interbase exercise would be enough to make many take a wait and see position. Why invest in supporting an open source project which is closed again after some months?

History shows that the US looking after its own interests has had us paying most of the costs of defense for Europe since WWII. You are entitled to your own opinion, but not your own facts. That said, this thread is wildly off topic, and I will write no more of this.

Truly a bit surprising, but if they continue to include that old palette, then they should at least ensure that it works.

Combativeness is not a tool of persuasion. As to China, wake up and smell the tea. They plan to dominate us as soon as possible, and technology is at the heart of their interests.

Many years ago, I knew an instructor form UC Santa Cruz who could speak endlessly on the irregularities of C syntax, which are legion.

There you go again, charming those you wish to persuade. As a matter of fact, however, your desire that the compiler be open sourced in no way justifies your assertion that it needs to be open sourced.

It is still GPF under the covers, as in the Wikipedia article here: https://en.wikipedia.org/wiki/General_protection_fault The jargon comes from the x86 CPU family. The AV term is discussed here: https://en.wikipedia.org/wiki/Segmentation_fault

You saved me form the same temptation!

While you antagonize those who will make the actual decision? Votes can be ignored, and have been for years.

If we discuss having used those, we date ourselves. 😉 I still have my TP1 for Z80 manual.

Exit, Break, and Continue all seem to me to be structured GOTOs. They interrupt the flow, but in a well ordered way. Well, at least when used properly, it is well ordered.

Does no one read Alan Cooper any more?

I would add that any dialog which reports an error condition should allow the user to copy the text to the clipboard.

General Protection Fault. An exception, and a term not often seen in current discussions.

I hid the Procedure List Toolbar, and cannot find how to unhide it. Can you help me recover from that blunder?

My apologies. The toolbar in question is in CnPack, not in GExperts.

Rules are made to be broken. (Except this one!) Consider the "Law" of Demeter. which proposes that drilling down through layers is a bad thing. Then consider: MyCaption.Font.Color := clRed; Does it really make sense to have to write: _font := MyCaption.Font; _font.Color := clRed; And if layers of dotted notation makes for bad practice, then what does that make of Fluent coding? Sometimes, inheritance is the best choice, but the deeper the inheritance -- in my view -- the more likely it was a bad choice. Sometimes composition is the best choice, but things become murky when some of the members are best assigned dynamically; then you need also consider whether Property DI is a better choice than Parameter DI. And sometimes, a simple function is just fine.