
I’d like to suggest a small comment enhancement in the IDE
if I start a comment with //– or //== or //__ – the Editor should embellish as below. Perhaps the same for /// comments too?

I’d like to suggest a small comment enhancement in the IDE
if I start a comment with //– or //== or //__ – the Editor should embellish as below. Perhaps the same for /// comments too?
It’s been a while since the last road map.
Until the powers that be provide us a new one – what feature(s) would you like to see in the next Delphi city?
Some of my whimsical desires include…
– More fixes for known issues
– Proper High DPI management built into VCL (multi DPI image lists, etc) and a proper overhaul for the IDE to rid it of scaling issues
– RTL performance improvements for generics and multithreaded memory management
– A default out-of-the box cross-platform exception stack tracer with API for plugging in enhanced custom stack tracers, information providers and logging mechanisms
– Code generation improvements utilising more modern CPU features
– Beacon/IoT support for VCL/Windows platform
Anonymous Method constraints
Due to the occasional shooting of foot due to how capture works, I wish there was a way of optionally constraining references for an anonymous method, so that I could enforce local references only.
type
TFilterMethod = constrained reference to function (const Item:T):Boolean;
TInstanceList = class
property function Filtered(Filter: TFilterMethod):TInstanceList;
end;
var
SomeRef: TQualifier;
List: TInstanceList;
Element: TThing;
begin
…
// compiles
for Element in List.Filtered(function (Item: TThing)
begin
Result := Item.Qualifier in [This, That]);
end)
do begin
…
// should not compile – but error on “reference outside method not allowed for constrained methods
for Element in List.Filtered(function (Item: TThing)
begin
Result := (Item.Qualifier = SomeRef);
end)
do begin
…
The Perils of Format
Format is good. Format is bad.
The good is that you can create very nice translatable strings which can deal with reordered parameters, and that perform fairly well.
if Language = Yoda
then fmt := ‘%1:s apples, %0:d you took.’
else fmt := ‘you took %0:d %1:s apples.’; // English
Writeln(Format(fmt, [5, ‘green’]));
So, what is the pain? All the checks are done at run time.
Let me repeat that: … at run time.
Once again, during a hotfix, I blew it on the parameter type, mistakenly passing a Double into the position where an Integer was expected.
I really wish that there was compiler magic that could validate the type and position of the Format parameters at compile time. Until there is, I will be careful to send all parameters as strings, and convert to string in the Format argument list – at least for the quick fixes.
CreateProcessWithLogonW
Neat routine that still is missing from WinAPI.Windows.pas.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682431(v=vs.85).aspx
Type inference and inline declarations
(Copied from a comment I wrote on Non-tech.)
I would like to see more scope fencing through inline declarations and automatic type inference.
for aItem in myList do if Pos( ‘widget’, aItem ) > 0 then listbox1.Items.Add( aItem );
aItem doesn’t really need a declaration if the list is a TList or in any other way expose a type through the default property.
Should I need to cast the type of an iteration variable, it could be done like: for aItem:String in myList – and still be possible to type check at compile time.
I think inline declaration would be very good for iterators – so that you don’t mix variable and iterator use – such as first using it in a for loop iteration and later reuse it as a reference variable.
Scope limited temporary variables would also be great.
Alt.1
using A:TThisType, B:TThatType
begin
// The simple reference variables A and B only exists within this scope.
end;
Alt.2
using auto A:TThisType, B:TThatType
begin
// A and B are created on entering and destroyed on exiting this scope.
end;
And then there is the dreaded with statement which could be replaced by a type inferred reference
using A as Some.Object.List[Index]
begin
// A only exists within this scope
A.Value := ..
end
A would be typed from the list element type, and if you need a cast
using A:TSomeType as Some.Object.List[Index]
begin
// A only exists within this scope
A.Value := ..
end
That would also be type checkable at compile time.
XE6 still stuck on an old SVN version.
We need an easy way to solve this problem.
Conditional Defines
I often wish I’d could have a LARS defined globally for my IDE, so that my sordid testcode was ignored when other team members built my code.
Generics and enumerations
We need a type qualifier for enumerated types that allow us to do loops and indexing with generic enumerables.
type
TMyType = (a, b, c);
TEnumToStr = reference to function(Value:T):String;
procedure SomeClass.ListTypes(ToString:TEnumToStr);
var
v: T;
begin
for v := Low(T) to High(T) //<– Error
do Writeln(ToString(T));
…
[dcc32 Error] : E2032 For loop control variable must have ordinal type
Argh!
Any suggestion to for a clever workaround? I need to write tests for dozens of EnumToString functions for enumerable types, and would love to avoid having to recreate the entire loop with declarations, sanity checks, logging and all.
It would be nice if the Windows APIs were properly covered in Delphi.
Marco Cantù – It seems that you missed this little handy function.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376399(v=vs.85).aspx
You must be logged in to post a comment.