I really love the “name spaces” you can create with records and constants.

I really love the “name spaces” you can create with records and constants.


mime = record

public const

ApplicationJson = string(‘application/json’);

TextHTML = string(‘text/html’);


Response.ContentType := mime.TextHTML;

12 thoughts on “I really love the “name spaces” you can create with records and constants.

  1. The point is that is a typed constant and not a true constant. It’s a constant, it is always a constant, but some parts of the language require the use of true constants.


  2. To give an example – typed constants are not considered to be constants in cases like these:

    // This is OK


    MyDefault = string(‘Oh noes’);

    procedure LogError(const Msg:string = MyDefault);


    DebugOut(Format(‘Error: %s’, [Msg]));


    // This is not OK


    MyDefault2: string = ‘Oh noes’;

    procedure LogError2(const Msg:string = MyDefault2);


    DebugOut(Format(‘Error: %s’, [Msg]));


    and gives you [dcc32 Error] : E2026 Constant expression expected

    at LogError2


  3. I seriously hate this consts that are no true consts and thus cannot be used everywhere where consts can be used – plus one for language inconsistency because of technical debt in the compiler.


  4. Lars Fosdal You’re making me cry. Back in the CodeGear days Nick Hodges proposed having a compatibility mode and a “nextgen” mode for the compiler going forward, allowing them to break legacy compatibility and introduce new features…

    Here we go, from way back in 2009….

    ” So the question becomes: How to modify the Delphi front end to enable new and modern language features while still ensuring that your valuable code works?

    What if we created a new compiler front end that gives you the choice between a new, non-legacy syntax and the older way of coding? (Let me be clear again: we are not talking about removing language features. If you are firing up the comments to ask “So, what code constructs are you going to deprecate?,” I answer that now by saying “None. All you code will still work.” We should be pretty clear on that by now, right?) Or better yet, how about a new way of viewing existing code and “new” code so that they can work together, allowing you to put new code in new modules while keeping your old code working as it always has? Existing code would all still be able to be injected into the new way of doing things, but if you wanted to use the “new and improved” stuff, you’d have to do it in the new type of code module? And how about if, while we are at it, we end up creating a DCU (or something akin to what DCUs are today) format that aren’t compiler version specific. How does all that sound?

    That sounds pretty cool to me, but of course, doing something like that isn’t trivial, and would require a serious amount of time and effort. But something like that would be worth it, no? ”


    Sigh… what could have been…. This, combined with branching out to offer products for other (more popular) languages, would have effectively combined the strategies of RemObjects and JetBrains and given a cheaper, more modern and powerful product with a fully functioning IDE. It would have been a “Happily Ever After” for the next era of Delphi.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.