Träume, Wünsche und Wahnvorstellungen...

[s.h.a.r.k]

• Viele Fixes in der Sprache -- siehe allein schon mal die Generics.
• Wie wäre es mit einer getrennten Entwicklung von IDE und Compiler? Dies könnte man auch mit der Idee einer kostenlosen IDE verknüpfen, die einfach weniger Optionen bietet.
• Anpassung der Sprache an aktuellere Sprachen samt Patterns, z.B. richtige Singletons. Klar, man kann wieder über deren Sinn und Unsinn diskutieren, aber die Sprache Delphi sollte mal wieder etwas moderner werden und könnte somit auch wieder eher in den "Mittelpunkt" rücken. Die "Delphi-stirbt-doch-eh-bald"-Threads sind ja auch nicht ganz unbegründet.
• Allgemein Erweiterung der IDE um mehrere "Experten". Man könnte sich so viel von bekannten Experten abschauen und effektiv einbauen.
• Git/Mercurial einbauen.
• Alle Compiler-Fehlermeldungen dokumentieren

Zitat:

beim Speichern/Debuggen läuft standardmäßig die Codeformatierung über alles drüber

Ich würde die IDE nach dem ersten Mal umbringen, wenn sie das machen würde Daher wäre sowas eher ein NO GO

[Phoenix]

Zitat von s.h.a.r.k:

Zitat:

beim Speichern/Debuggen läuft standardmäßig die Codeformatierung über alles drüber

Ich würde die IDE nach dem ersten Mal umbringen, wenn sie das machen würde Daher wäre sowas eher ein NO GO

Für mich ist das ein Must-Have. Idealerweise läuft vor dem Check-in in die Versionierung sogar ein Check über die Formatierung und lehnt falsch formatierten Code ab. Freilich muss das aber bis ins letzte Detail konfigurierbar sein um den eigenen Styleguide festzulegen.

[mirage228]

Was mir gerade, neben einigen bereits erwähnten Punkten, noch einfällt:

• Integrierte (native) Multicast Delegates - sowohl für eigenen Code als auch in der VCL, z.B. alá Button1.OnClick.Add(ZweiterEventHandler);.

[Namenloser]

Zitat von mirage228:

was mir gerade, neben einigen bereits erwähnten punkten, noch einfällt:

• integrierte (native) multicast delegates - sowohl für eigenen code als auch in der vcl, z.b. Alá button1.onclick.add(zweitereventhandler);.

+1.

[uligerhardt]

Zitat von NamenLozer:

Zitat von mirage228:

was mir gerade, neben einigen bereits erwähnten punkten, noch einfällt:

• integrierte (native) multicast delegates - sowohl für eigenen code als auch in der vcl, z.b. Alá button1.onclick.add(zweitereventhandler);.

+1.

...und nochmal +1!

[himitsu]

theoretisch existieren die schon
http://www.delphipraxis.net/132817-u...ler-e2506.html

[Deep-Sea]

Naja, TDictionary existiert ja auch schon. Aber ich meine eher so wie in PHP. (Ich Verräter! )

[mkinzler]

PHP funktioniert auch ganz anders.

[Elvis]

Zitat von Deep-Sea:

Naja, TDictionary existiert ja auch schon. Aber ich meine eher so wie in PHP. (Ich Verräter! )

Man sollte isch sehr genau überlegen, ob man Features als Sprachfeatures haben will, die genauso durch Libraries abgedeckt werden können.
Denn dadurch bleibt die Sprache sauber (wobei das bei diesem furchtbaren Kuddelmuddel, was sich Delphi Language nennt, wohl kaum noch erreichbar ist) und du kannst eine andere Implementierung wählen, wenn du mit der verbreiteten unzufrieden bist.
Damit aber Features sinnvoll durch Libraries implementiert werden können, muss die Sprache viel weniger pain-in-the-butt werden. Type-inference und ExpressionTrees sind schon fast Voraussetzung um Libs zu schreiben, die in ihrer Verwendung fast natürlich erscheinen.

Ohne einen Clean-Slate, also Delphi 2.0, sehe ich aber auf Dauer keinen Sinn in so einem Unterfangen.
Delphi ist ein Konglomerat aus 20+ Jahren Computergeschichte, von der ein Großteil eigentlich irrelevant sein sollte. Dummerweise schleppt man den alten Käse noch mit und deshalb sieht Code in Delphi im Jahre 2011 nur marginal besser aus als 1995.

[s.h.a.r.k]

Zitat von mirage228:

Was mir gerade, neben einigen bereits erwähnten Punkten, noch einfällt:

• Integrierte (native) Multicast Delegates - sowohl für eigenen Code als auch in der VCL, z.B. alá Button1.OnClick.Add(ZweiterEventHandler);.

Wäre fast mal die Zeit wert, sowas via Class Helpers nachzurüsten