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
I’d like to see an AppMethod exe for Mac entirely based on cross-platform code 🙂
I’d like to see threadsafe Set8087CW and SetMXCSR, and a change to the handling of external exceptions to no longer modifies 8087CW and MXCSR.
64 bit IDE 🙂
+1 for the high DPI management
Less new bugs, fixing existing ones.
I’d be happy with high dpi and much more stable IDE(the only thing that actually makes one productive from the whole package IMO)
High performance datasnap?
– High DPI VCL
– New code gen (via compiler switch): SSE…etc.
– Up to date modernized VCL (paths, regions, PDF, PS, etc)
… and finally
-Linux + Webbroker
I’ll dream big:
– Vastly improved type deduction for generic type parameters.
– Lambda keyword/syntax for short anonymous methods.
– New generic constraint “enumerable”, so I could use “for..in” inside my generic methods on instances of the generic type.
Asbjørn Heid I don’t think that there should be any need for an enumerable constraint. The existing class constraint should be enough. So this really should compile:
type
TMyClass = class
private
type
TEnumerator = record
private
FCurrent: Integer;
public
property Current: Integer read FCurrent;
function MoveNext: Boolean;
end;
public
function GetEnumerator: TEnumerator;
end;
TMyGeneric = class
public
procedure Foo(Instance: T);
end;
{ TMyClass.TEnumerator }
function TMyClass.TEnumerator.MoveNext: Boolean;
begin
end;
{ TMyClass }
function TMyClass.GetEnumerator: TEnumerator;
begin
end;
{ TMyGeneric }
procedure TMyGeneric.Foo(Instance: T);
var
i: Integer;
begin
for i in Instance do
;
end;
But it does not. It fails with
[dcc32 Error] Project36.dpr(41): E2430 for-in statement cannot operate on collection type ‘T’
On the other hand if the loop is written like this:
for i in TMyClass(Instance) do
Then all is sweetness and light.
An enumerable constraint would likely not fit into the existing generics design. The reason being that the compiler does the compilation on the generic type rather than the specializations. Now, if you had an enumerable constraint, that would not fit because GetEnumerator can be implemented in many different ways. Each specialized type might implement it differently.
Ref. Generics – I would like to specify Enumeration as constraint so that I could use enumeration functions like Ord(T(Item)) and define internal types like Set of T and use set operators;
+Lars Why not ord(Item)?
David Heffernan But that would not allow me to pass a record or interface instance, both which can satisfy the enumerable condition, nor arrays.
The compiler currently does duck-typing-style lookups for this, so I’m thinking it should/may be possible to plug the machinery which determines if some type T supports enumeration into the generic constraint verification routine.
Lars Fosdal In general I long for user-definable constraints, but I’m trying to be half-way realistic here 🙂
David Heffernan Because you can’t do Ord on a variable of type T as it is not constrained to an enumerated type – similar to the way you can’t do T.Create on a T that is not constrained to a class with a parameterless constructor.
That said: There are workarounds – but it’s a bit kludgey: Example:
[TestFixture]
TestConstantEnumToStrings = class
private
protected
function TestConstantEnumToStrings.TestEnumToString(const Method: TEnumToStringFunc; Language: String): Boolean;
type
PointerOfT = ^T;
var
EnumAsString: String;
CaseResult: Boolean;
ix: Integer;
TI: PTypeInfo;
fx,tx: Integer;
begin
Result := True;
TI := TypeInfo(T);
Assert.IsTrue(TI.Kind = tkEnumeration, ‘Type passed is not an enumeration’);
fx := TI.TypeData.MinValue;
tx := TI.TypeData.MaxValue;
for ix := fx to tx
do begin
EnumAsString := Method(PointerOfT(@ix)^, Language);
CaseResult := Pos(‘ToString not implemented for language’, EnumAsString) <= 0;
if not CaseResult
then TDUnitX.CurrentRunner.Log(TLogLevel.Error, EnumAsString);
Result := Result and CaseResult;
end;
Assert.IsTrue(Result, ‘Type ‘ +String(TI.Name) + ‘ is missing ToString value(s) for language “‘+Language+'”‘);
end;
More compiler checks. E.g. NameOf(property)
Lars Fosdal Once you had the constraint, you would not need to cast, right? After all, you said:
“so that I could use enumeration functions like Ord(T(Item))”
Asbjørn Heid That’s my point. Whilst the duck-typing implementation of for .. in works with concrete types, I cannot see it working with generics, given the current implementation. The compiler compiles the generic code, rather than the specialized code. As I understand it.
Further improvements of FMX performance.
Nicholas Ring What would be the benefit of a 64 bit IDE? I personally don’t care whether it is 32 or 64 bit, so long as it works.
/sub
David Heffernan I agree that it is likely not a trivial addition. But there has been many cases where I had longed for this, so I’ll put it out there 🙂
1. Continued FMX improvements and fixes
2. Ability to write console apps on Linux
David Heffernan Right – If T was constrained to an enumerated type, the associated type declarations, functions and operators would work. Typo, I guess: “so that I could use enumerated type functions like” would be more appropriate. Ord, Low, High, Pred, Succ only works for enumerated types. Technically, Low/High works for arrays too – but that is an “overload”.
If a 64-bit IDE would work better with a 64-bit debugger, I am all for it.
My wishes:
– More updates/fixes, less upgrades (making it easier to keep 3rd party components usable for a longer time)
– 64bit IDE (=easier development with 64bit only OCXs like AutoDesk components)
– consistent UI for all IDE elements and dialogs (please support VCL styles and don’t reinvent the wheel for the IDE styling = dogfooding your own UI controls and techniques)
– unbundling of 3rd party components/tools and make them available via GetIt
– better copy protection (=faster startup, no sudden IDE shutdown due to false piracy detection)
– floating licenses (use Delphi on any machine with your EDN account – e.g. for testing in different OS VMs)
Smaller executables, faster performance.
David Heffernan Why 64 bit IDE you ask? Because Emb did a patch job to get over the out of memory issues that are affecting people on a daily, if not hourly bases.
2GB was fine until a few years ago. How much time do you think before 4GB isn’t enough?
Because applications aren’t getting smaller and the amount of memory the compiler needs isn’t decreasing.
Because the IDE is growing with functionality, either built in, or via its plug-in mechanism, and I doubt any of that doesn’t use extra memory (IDE Fix Pack might be the only exception here).
Do you think that the Windows platform will be 32 bit application compatible forever?
If the IDE goes to multiple platforms, do you think it will be 32 bit still or, as most OSes now days are 64 bit, 64 bit?
So many reasons for a 64 bit IDE 😀
Real db controls in FM instead of having to use livebindings
/sub
Extended “with” syntax, like that:
with A: SomeParam, B: AnotherParam do
begin
A.SomeProp := B.SomeProp;
A.DoSomething;
end;
Nicholas Ring If 64 bit IDE isn’t needed then why bother? If x-plat IDE isn’t needed, why bother. On the other hand, if some design time aspects need third party libs that only exist in 64 bit form, then that’s a different matter.
David Heffernan But a 64 bit IDE is required for the reasons I mentioned. And Embarcadero knows it! Why else would they put work arounds such as external compiling and enabling large aware address mode? Because of memory issues. If you aren’t hitting these problems, then all the best to you! For me, I can be a lot more productive if the IDE had more memory to use.
Question: Why did Delphi 2 go to 32 bit when Delphi 1 was only 16 bit?
One good thing about the 32-bit IDE: Emba is forced to keep the memory usage low! For real!? Stupid idea!
Nicholas Ring I think Embarcadero are best placed to know how to implement their product. Maybe 64 bit IDE is needed, but we can’t really know for sure. I always hate it when my clients tell me that I’ve implemented something the wrong way, and of course they don’t have the full picture to make such comments.
What I’d like to see though is for the IDE to be less dependent on weird and wacky third party code, like the J# stuff. I think if they could get clean pure 100% Delphi code then it would be easier for them to do things like 64 bit, x-plat and so on. Of course x-plat would be a huge step because IDE is built on VCL.
Of course, that last paragraph was me doing what I hate my customers doing, so take with pinch of salt!
David Heffernan I can function with a 32-bit IDE, but eventually, we do need to leave 32-behind. 64 bit CAN address 16 exabytes of memory, even though it’s not practical. My windows PC has 32 gb memory, but 32 bits can only address 4gb (maybe less).
+Phillip As I keep saying, if the user sees no benefit, what’s the point. I for one don’t want Emba to spend time on something that brings no benefit. That would be at the expense of some other development.
Again, if a 64 bit IDE has significant benefits, so be it.
Shouldn’t we let Emba decide? Aren’t they best placed?
David Heffernan I’m not saying that they need to do it now, but perhaps in the future? Maybe when we move to 128 bit machines?
Anyway, I’m sure Emba know what they are doing. They’ll not take on this task unless there’s a good reason to do so.
David Heffernan
>Anyway, I’m sure Emba know what they are doing.
I am sure they do but not to what the user base wants and a company needs to listen to their user base for what they need. If not, they will fail.
Examples that come to mind are:
* Change of the license to stop the Professional version from having any database access (they soon reverted that, didn’t they)
* IDE memory issues (either external MSBuild or the large address aware, and they sure pull out the stops for the later)
>They’ll not take on this task unless there’s a good reason to do so.
64 IDE is a nature progression from large address aware, and now they have (hopefully) identified all the locations within the IDE where it needs to be touched to get it there.
But what you say is true. They will not take on this task unless there is benefit for them to do so. However, the question that Lars Fosdal asked was:
what feature(s) would you like to see in the next Delphi city?
And a 64 bit IDE is what I (and others going by the +1s) would like to see. The likelihood of actually seeing it, I guess, would be close to zero in reality but it doesn’t mean it isn’t a feature that I would like to see.
Nicholas Ring I don’t understand your logic. Let’s assume, for the moment, that there’s no benefit to the users of a 64 bit IDE. If you knew that, you’d still like Embarcadero to spend significant development resource on that to the detriment of something else?
David Heffernan I don’t understand why you are still arguing? Just because it won’t benefit you, doesn’t mean it won’t benefit others.
But to follow your example, do you mean like FireMonkey? I have no interest in FireMonkey, or cross platform compiling and because of it other things have not been addressed. But I do see the benefit to others for it.
I will repeat, Lars Fosdal asked:
what feature(s) would you like to see in the next Delphi city?
I took this a a rhetorical question and I answered it with what I would like to see. I have answered your question on what benefits it would bring, yet you still don’t like the answer – why?
Nicholas Ring I don’t understand your logic. You are arguing that you might want Embarcadero to spend development resources on features that would be of no benefit to anybody.
I clearly understand that not all features are useful to all users. As a software developer I know that well with my own users. However, you seem to be arguing in favour of adding features that would be useful to nobody.
Note that I’m not claiming that 64 bit would be useful to nobody. Just that it could conceivably be useful to nobody. And given that possibility, and given that I’m aware of no evidence that 64 bit IDE brings any benefits, I don’t see how anybody could take the stance that you are taking.
David Heffernan Just because you aren’t aware what 64 bit IDE would bring doesn’t mean that there isn’t any. Maybe you should stop complaining/arguing about a person’s opinion and think about the possibilities.
Some possibilities that could be done (and trust me when I say that it is my imagination that is stopping me):
* Compile Group projects which contain large projects,
* 3rd party (IDE plug-in) refactoring tools (would require a fair bit of memory to handle large projects)
* plug-in to communication with 64 bit processes (64 bit applications are becoming the norm)
I am sure that others could think of other features that could be done within the larger memory…
+Nicholas It’s not the details. It’s the principle. I don’t understand why you would argue for a development to be done irrespective of whether or not its beneficial.
Suppose that all the things you mention could be achieved with 32 bit IDE. You’d still like to see a 64 bit one for the sake of it? I don’t believe that.
David Heffernan
>Suppose that all the things you mention could be achieved with 32 bit IDE.
No it can’t. The main project at work falls over regularly (at least once per hour!) due to out of memory issues (it is on XE but it is 32 bit). Maybe Seattle would improve this but it would only be a matter of time before it starts again…
+Nicholas By all accounts Seattle solves the problem.
When you ask for a 64 bit IDE what you mean is an IDE that is stable and can operate without exhausting memory. You really don’t care how Emba do that, so long as it works.
But my argument is all about the principle. On the premise that a 32 bit IDE works as well as. 64 bit IDE in all regards, surely you would not want Emba to spend their resources on a 64 bit IDE.
David Heffernan No, Seattle is delaying the problem (as did external MSBuild).
No, I didn’t mean that. I would like 64 bit IDE so I can have more memory to play with. It isn’t just the IDE, it is also the plugins I want to run too, and they also use memory.
Exactly my point, you are arguing against my answer, for a question that is based on people’s opinion.
+Nicholas We are talking at cross purposes. I’m making a conceptual point. Which you don’t seem to appreciate. Never mind.
David Heffernan I didn’t appreciate it because it wasn’t in the spirit of the question (IMO). If I interpret the question incorrectly, then I do apologize to everyone here and special to Lars Fosdal for making a mess of his question.
If I thought the question was serious and that Emb would actually act upon it, then my answer would have been different, as a 64 bit IDE would be a while off (as the changes in Seattle for memory would be enough for Emb to work on other priority issues).
If I wanted to be totally out of the park, I would love a compiler that compiles to C=64 – That would be freaking awesome! Practical, no but still awesome!