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

[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.

[stahli]

Zitat von NamenLozer:

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.

Die Antwort findest Du dort.


[etwas OT, aber wenn man gefragt wird...]Wunsch: Julia sollte mich entgegen der Absprache doch anrufen. Traum: Sie sollte vor Oktober wieder kommen. Wahnvorstellung: Nee, sage ich nicht.[/etwas OT, aber wenn man gefragt wird...]

[bernau]

Zitat von stahli:

- 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))

Au ja. Das zähle ich zu den wichtigsten Dingen. Ich arbeite sehr viel mit Frames. Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

[rollstuhlfahrer]

Zitat von bernau:

Es nervt immer wieder, wenn man "ausversehen" etwas in einem eingefügten Frame anklickt/verschiebt/ändert.

Eine Undo-Funktion für visuelle Komponenten.

Bernhard