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

[Elvis]

Zitat von Phoenix:

Zitat von hanspeter:

Mein Wunsch Kompatibilität zu Assemblys. Ablösung der umständlichen BPL. Eine Schnittstelle zu WPF.

Hydra?

Basiert Hydra nicht immer noch auf BPLs? Hilft also recht wenig was Kompatibilität angeht.
Man kann immer noch nur "Assemblies" in einen Prozess laden, die mi der gleichen Compiler-Version gegen die gleichen Package-Versionen (read:VCL/RTL) kompiliert wurden.

[Thom]

Unterhalten sich zwei:
- Siehst den Alten da hinten? Kann man mit dem Ding überhaupt noch fahren?
- Hey - guck mal, wie mein Auto aussieht. Geil was?
- Boh eh - aber da mußt du dir mal meins reinziehen. Das ist ja sowas von aufgemotzt. Das springt schon an, wenn ich die Tür aufmache.
- Mit was fährt deins?
- Aral. Das ist cool! Und deins?
- Shell. Das ist doch viel schicker!

Und damit schalte ich mich ebenfalls in den invisible-mode, um in Ruhe darüber nachdenken zu können, ob ich lachen oder eher weinen soll...

[mkinzler]

Oder man verwendet Delphi.Prism, dann werrden automatisch Assemblies verwendet.

[Codewalker]

Für Delphi würde ich mir wünschen

• Vernünftig dokumentierte API um Experten zur schreiben
• Den Mut bei Embarcadero, mehr Vertrauen und Verantwortung in die Community zu legen. Die automatisch erzeugten Einträge in der Hilfe und der Wiki (XX.YY ist ein Member das Klasse XX) hätte man auch einfach weglassen können. Wäre ehrlicher gewesen und suggeriert nicht "da ist was" obwohl da eigentlich nix ist. Die Community und viele Einzelne haben viel, was Delphi verbessern kann (die JCL, Andreas Hausladen, das DEC .... die Liste ist lang und es gibt sicher nicht wenige in der Community, die mitmachen würden).
• Die Sprache von der IDE zu lösen. Die Verbindung hat (im Gegensatz zu Java & Co) zur Folge, dass viele neue Features nur wenig genutzt werden, weil sie halt nicht jedem zur Verfügung stehen und nervige Fehler (z.B. der Enumerator bei den Generics) nicht für alle, sondern nur für extra-zahlende gefixt werden. Warum nicht die IDE für Euros anbieten, den Compiler gibt für OpenSource und Freeware gratis (das lockt wieder neue Leute in die Sprache, was wirklich nötig ist) und wer mit Delphi Geld verdienen will, der holt sich halt eine Compilerlizenz (meinethalben mit Laufzeit 1 Jahr, damit regelmäßig Geld in die Kassen kommt). Firmen werden es sowieso machen und werden es befürworten, nicht immer für neue Sprachfeatures gleich die IDE wechseln zu müssen.

naja und die Traumliste:

• Entschlackung und anschließende Standardisierung der Sprache
• Cross-Compiling für Windows,Linux,Mac (im Smartphone-Markt ist mit einer Delphi-IDE imho nix zu holen)
• mehr Transparenz seitens Embarcadero (z.B. verbindliche Roadmap (ich sag nur 64-Bit), mehr Präsenz in den Communities)

[Der Jan]

VCL-Designer und Delphi-Toolchain als Netbeans-Plugin ...

Bei den Sprachfeatures halte ich mich mal zurück. Bin ja schon über die Generics heile froh

Crosscompiling wäre nice.

[Codewalker]

Ist mir doch gerade noch etwas aufgefallen, was fehlt: Der blöde E2195 muss weg, ich will endlich lokale Variablen initialisieren können. Compilermäßig dürfte das wenig Aufwand sein.

Delphi-Quellcode:

procedure TuWas;
var
 i: Integer = 1;
 S: String = 'Test';
begin
{ ... }
end;

Und Zuweisungsoperatoren a la C++ wären auch nett:
 i += 1;

[stahli]

Tools:
- integrierter Ressourcen(Icon-)Editor

Debugging:
- Debuging für einzelne Unit bzw. Package in Projektoptionen deaktivieren
- Bereichsprüfung standardmäßig ein
- Überwachte Ausdrücke: Weg"Optimierung" von Self abschalten
- Haltepunkte händisch und automatisch (Unit+Zeile) sortieren
- Umsortierung überwachter Ausdrücke per Drag&Drop

Compilierung:
- Fehlerinfo bei Compilierungsfehler weglassen und direkt zu Quelltext springen (war bei D2009 noch so, in XE muss erst Fehler bestätigt werden)
- Gleiches gilt für Infofenster nach Compilierung abhängiger Packages (die Nachricht (neu in XE) ist unnötig)

IDE:
- UnitRegister optional MultiLine
- SplitEditor
- Frames als Blackbox markieren (Änderungen innerhalb eines Frames im Formular sowie auf Wunsch Darstellungen der enthaltenen Controls verhindern (nur graue Fläche mit Frame-Namen))

Features:
- zirkuläre Unitreferenzen ermöglichen (wenigstens teilw. z.B. durch Deklarationen wie MyClass = class in OtherUnit; (Da die Foreward-Deklaration in einer Unit geht, sollte sich dies auch Unit-übergreifend realisieren lassen.)
- Automatische "Nilung" von freigegebenen Objekten und Referenzen darauf (also ein integriertes Observer-Patterns).
- Data-Bindings (an denen Stevie ja bereits arbeitet)
- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel )
- try .. except .. finally .. end
- Und VOR ALLEM einen brauchbaren und in Delphi integrierten OR-Mapper (z.B. ala ECO). (Ok, das wäre eine zu starke Konkurenz zu meinen odControls - also ziehe ich den Wunsch lieber zurück )

[Namenloser]

Zitat von stahli:

- FinallyExit (fände ich trotz allem besser als das try-finally-Gewurschtel )

Ich glaube damit stehst du ziemlich allein. Warum sollte man das exakt selbe Feature doppelt implementieren? Bei den restlichen Punkten stimme ich dir aber weitestgehend zu.

[himitsu]

> zirkuläre Unitreferenzen ermöglichen
lieber nicht
Klar, es würde teilweise einiges einfacher machen, aber auch viele Fallstricke eröffnen.
(PS zirkuläre gezieungen geht nicht, die Interface-Abschnitte dieses nicht zulassen)

FinallyExit lieber nicht (PS: hier hassen eh viele die GOTOs ), aber bei try..except..finally..end wäre ich dabei

Zitat:

Und Zuweisungsoperatoren a la C++ wären auch nett:

Aber nur, wenn als Erweiterung des := , also nur für Zuweisungen
und blos nicht innerhlab von IFs und Co.

[himitsu]

> zirkuläre Unitreferenzen ermöglichen
lieber nicht
Klar, es würde teilweise einiges einfacher machen, aber auch viele Fallstricke eröffnen.
(PS zirkuläre gezieungen geht nicht, die Interface-Abschnitte dieses nicht zulassen)

FinallyExit lieber nicht (PS: hier hassen eh viele die GOTOs ), aber bei try..except..finally..end wäre ich dabei

Zitat:

Und Zuweisungsoperatoren a la C++ wären auch nett:

Aber nur, wenn als Erweiterung des := , also nur für Zuweisungen
und blos nicht innerhlab von IFs und Co.

Das wäre dann sogar halbwergs kompatibel zur := -Syntax
[:+-*/]=


Über Record-Operatoren für "Standard"-Typen, könnte man die Multi-Events für OnXYZ leicht nachbauen.