I really love the “name spaces” you can create with records and constants.
type
mime = record
public const
ApplicationJson = string(‘application/json’);
TextHTML = string(‘text/html’);
end;
…
Response.ContentType := mime.TextHTML;
I really love the “name spaces” you can create with records and constants.
Published
I like it.
Why the explicit string cast?
Uli Gerhardt I am a creature of habit. This way there is no doubt of the actual type and encoding. I do the same for Byte, Word, Integer, Cardinal.
Lars Fosdal what about:
const Foo: string = ‘Foo’;
Alexander Benikowski – Unfortunately, that is not accepted as a constant under all circumstances.
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.
To give an example – typed constants are not considered to be constants in cases like these:
// This is OK
const
MyDefault = string(‘Oh noes’);
procedure LogError(const Msg:string = MyDefault);
begin
DebugOut(Format(‘Error: %s’, [Msg]));
end;
// This is not OK
const
MyDefault2: string = ‘Oh noes’;
procedure LogError2(const Msg:string = MyDefault2);
begin
DebugOut(Format(‘Error: %s’, [Msg]));
end;
and gives you [dcc32 Error] : E2026 Constant expression expected
at LogError2
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.
Perhaps it is time to draw a line in the sand and create a Next Generation Pascal Compiler (NGPC) that sheds all the debt and break a lot of code?
Stefan Glienke This is indeed almost as bad as Scotsmen that are not true Scotsmen. 🙂
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? ”
http://edn.embarcadero.com/article/39174
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.
Joseph Mitzen You can’t have paradigm shifts without breaking code and/or libraries. BP -> TPW -> Delphi -> NGPC