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

[Robotiker]

Zitat:

Zitat von Elvis (Beitrag 1101979)

Aber all das ist komplett witzos in dem Babelcode, den Delphi momentan darstellt. Delphi braucht einen clean-slate, ein Delphi 2.0, um ohne den Turbo Pascal Krempel weitermachen zu können.

Hm, ich glaube eher nicht, das die Mehrzahl der Delphi Entwickler damit einverstanden wäre.

Im übrigen geht das mit der VCL schon seit über 10 Jahren :-D

Code:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
  auto_ptr<TStringList> foo(new TStringList);

  foo->Add("trööt");

  // Und automatisch weg ist die Stringlist ...
}

In C++ gibt es RAII, das ist viel besser als dieses using aus C#. :thumb:
http://de.wikipedia.org/wiki/RAII

[implementation]

Zitat:

Zitat von Elvis (Beitrag 1101979)

dass man eine richtige Syntax für Konstruktoren bekommt. (Nicht diesen komischen Krams in dem jeder seinen Ctor nennen kann wie er will und im Code sieht's aus wie eine statische Methode)

Also gerade die benannten Konstruktoren empfinde ich als einen Vorteil von Pascal gegenüber den C-Sprachen.
Ganz einfach, weil du so mehrere Konstruktoren haben kannst, z.B.:

Delphi-Quellcode:

constructor Create(const s: string);
constructor CreateFmt(const s: string; const args: array of const);
constructor CreateFromFile(const filename: string);

Klar, CreateFmt und CreateFromFile ließen sich als Klassenfunktionen deklarieren, aber was findest du verwirrender:

• 3 Konstruktoren, die zum Erstellen einer Instanz sind
• 1 Konstruktor, sowie 2 Klassenmethoden, die die Aufgabe von Konstruktoren übernehmen

Das Erstellen von Instanzen ist Konstruktorensache, es dann in Klassenmethoden auszulagern und ihnen eine andere Syntax zu geben als dem Konstruktor halte ich für unsauber.
Vergleiche bitte mal:

Delphi-Quellcode:

// schön
x := TKlasse.Create(..);
x := TKlasse.CreateFmt(..);
x := TKlasse.CreateFromFile(..);

// hässlich
x := new TKlasse(..);
x := TKlasse.CreateFmt(..);
x := TKlasse.CreateFromFile(..);

[implementation]

Zitat:

Zitat von Elvis (Beitrag 1101979)

und im Code sieht's aus wie eine statische Methode

Glücklicherweise gibt's in Delphi ja Klassenmethoden statt statische.
Hier wird noch heimlich ein Klassenzeiger (dass es die überhaupt gibt ist eine weitere Stärke) übergeben.
Der Vorteil: Klassenmethoden können dadurch virtuell sein und überschrieben werden :cyclops:


Ich habe eine Zeit lang nur mit C# programmiert.
Mir haben viele Features davon sehr gefallen, aber manches habe ich vermisst:

• Klassenzeiger, und damit verbunden auch virtuelle Klassen-/ statische Methoden
• Vernünftige Konstruktoren, die sind in C# nämlich nur Schrott:
  • nicht benennbar und
  • werden nicht vererbt :shock:
• Die Tatsache, dass array[a][b] = array[a,b] ist
• Mengen

Dies sind Dinge, die ich bisher nur aus Delphi kenne und die bitte auf gar keinen Fall abgeschafft gehören.

[himitsu]

Man sollte ienfach unterbinden, daß man Konstruktoren nur noch über Typen aufrufen kann und nicht über Objekte (bzw. daß es eine Compiler-Warnung gibt)
und schon ist das Problem behoben, was vorallem viele Anfänger haben, welche

Delphi-Quellcode:

Variable.Create;

anstatt von

Delphi-Quellcode:

Variable := Typ.Create;

aufrufen.

[Namenloser]

Also ich finde die Konstruktor-Variante unter Delphi eigentlich von allen Sprachen so mit am elegantesten, und zwar gerade weil der Konstruktor aussieht wie eine Klassenmethode. Passt doch super ins objektorientierte Schema: Die Klasse ist selbst dafür zuständig, eine Instanz von sich zu erzeugen.

Und dass man mehrere Konstruktoren haben kann, finde ich auch ein nettes Feature. Wer seinen Standard-Konstruktor anders nennt als

Delphi-Quellcode:

Create

ist imo selbst schuld... dass z.B. eigene Typen mit dem Präfix T beginnen schreibt Delphi ja auch nicht explizit vor, aber es ist die gängige Konvention.

[implementation]

Zitat:

Zitat von NamenLozer (Beitrag 1102043)

Wer seinen Standard-Konstruktor anders nennt als

Delphi-Quellcode:

Create

ist imo selbst schuld...

Im FPC gibt's eine Kommandozeilenoption, die auslöst, dass alle Konstruktoren

Delphi-Quellcode:

Init

und alle Destruktoren

Delphi-Quellcode:

Done

heißen müssen, sonst gibt's eine Fehlermeldung.
Die Option hab ich irgendwie mal in 'nen Projekt reingekriegt, und deshalb heißen da jetzt alle meine Konstruktoren und Destruktoren Init und Done :angel2:

[edit]
Laut diesem Dokument muss das wohl -Ss gewesen sein:

Code:

-Ss        Constructor name must be init (destructor must be done)

[himitsu]

Zu den Build-Ereignissen hätte ich auch gerne noch etwas Post-Build-Ähnliches, welches nach einem erfolglosem Compilierungsversuch ausgeführt wird.

[USchuster]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1101218)

• Viele Fixes in der Sprache -- siehe allein schon mal die Generics.

Das wird mit jedem Release gemacht. In Updates auch, aber da sind die Möglichkeiten schon allein dadurch beschränkt das keine Fixe eingebaut werden können die das DCU Format ändern und bei Generics passiert das häufiger als bei anderen Problemen.

Zitat:

Zitat von s.h.a.r.k (Beitrag 1101218)

• Git/Mercurial einbauen.

Was ist das? ;-)

Zitat:

Zitat von mleyen (Beitrag 1101269)

Wunsch: Das Emba den AHUser anheuert und ihm uneingeschrängen Spielraum gibt.
Begründung: Alles wird noch besser :-D

Jetzt kann er machen wozu er gerade Lust hat...

Zitat:

Zitat von himitsu (Beitrag 1101303)

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

Zu blöd das Du den Fehler nicht gemeldet hast, denn wenn Embarcadero davon nichts weiß, dann können die diesen Fehler auch nicht fixen.

Hoppla hab da doch einen Report dafür bei der Suche gefunden ;-)

Report No: 90767 Status: Reported
Regression: E2010 with multiple default properties in a generic type
http://qc.embarcadero.com/wc/qcmain.aspx?d=90767

Zitat:

Zitat von himitsu (Beitrag 1101437)

Eine Horrorvorstellung wäre, wenn Emba hier mitliest,
dann auch noch auf die wahnwitzige Idee verfällt einen unserer Wünsche umzusetzen

Matthias ist ja nicht mehr hier, da im Invisible Mode und sonst interessiert dieser Thread sicher niemanden ;-)

Zitat:

Zitat von RWarnecke (Beitrag 1101474)

Ich wünschte die würden endlich den Cross-Compiler rausbringen, damit ich Programme für Linux entwickeln kann. Das bräuchte ich ganz dringend, da ich gerade mehrere Linux-Server aufsetzen muss und zur Zeit alles versuche mit Bash-Skripten zu lösen.

Unterstützung kommt wahrscheinlich in Projekt "Wheelhouse" (? XE3, August/September 2012 ?)
(siehe Roadmap und ETA aus dem was David I über neue Releases erzählt)

Zitat:

Zitat von shmia (Beitrag 1101502)

Ich versuche meine Idee nochmal, aber diesmal eine Stufe schwächer.

Die VCL müsste als Repository (z.B. SVN) verfügbar sein und bestimmte Delphi-Cracks (ich denke da vorallem an die Jedi-Leute) haben Rechte zum Einchecken von neuen Revisions.
Mit der JCL wurde bewiesen, dass diese Leute qualitativ hochwertigen Code produzieren können.

Ich hätte lieber Zugriff auf den IDE Code...
Im Ernst: Allein schon aus der QA Perspektive halte ich das für bedenklich. Selbst gute Entwickler reisen hin und wieder mit dem A* was sein. (selbst Andy)

Zitat:

Zitat von generic (Beitrag 1101518)

Neben den 64bit Compiler könnte ich gut einen brauchen, welcher auch für ARM-Prozessoren kompiliert (für Windows 8).

ARM Unterstützung kommt vielleicht in Projekt "Commodore" (? XE4, August/September 2013 ?)
(siehe Roadmap und ETA aus dem was David I über neue Releases erzählt)

Zitat:

Zitat von stahli (Beitrag 1101758)

Tools:
- integrierter Ressourcen(Icon-)Editor

Mir würde es schon reichen der Resource Editor von Anders Melander würde sich in die IDE integrieren lassen. Nach Erledigung von folgendem QC Report müsste das gehen

Report No: 89028 (RAID: 277639) Status: Open
Custom Module support
http://qc.embarcadero.com/wc/qcmain.aspx?d=89028

Zitat:

Zitat von stahli (Beitrag 1101758)

IDE:
- SplitEditor

Für folgenden QC Report voten

Report No: 52968 (RAID: 222435) Status: Open
Add a horizontal / vertical splitter in the code editor
http://qc.embarcadero.com/wc/qcmain.aspx?d=52968

Für die Fälle wo ich es momentan gebraucht habe reicht mir ein Bookmark Viewer.

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1101781)

Zitat:

Zitat von bernau (Beitrag 1101778)

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

Eine Undo-Funktion für visuelle Komponenten.

Ich glaube das nervt viele.

Interessant ist hier der Thread Will D2010 Form Designer support undo/redo operations?


Eins noch zum voten für QC Reporte - ihr habt pro Report +/- 10 Votes und nicht insgesamt...außer ihr versucht es mit dem Webclient. Stattdessen den Win32 Client (in der IDE: Tools | Quality Central) oder QC Plus verwenden (auch wenns desupported ist).

[Medium]

Es ist schon recht auffällig, dass ein nicht zu kleiner Anteil der Wünsche (gerade auf den letzten 2-3 Seiten) sehr stark an .NET bzw. C# erinnern. Sollte ich nicht der einzige sein, der sich mittelfristig dort ein zweites Zuhause vorstellen könnte? :)

Ich bin da aber durchaus auf ähnlichen Straßen unterwegs. So manches Konzept aus der C#-Welt ist einfach Delphi in die richtige Richtung weiter gedacht, allerdings mit C im Hinterkopf. Dünke man ähnliches noch mal, aber dieses Mal mit Delphi aufm Schirm, könnte da was echt potentes bei rum kommen. Allerdings nicht, ohne zuvor den bereits benannten "clean slate" herzustellen. Von mir aus auch sehr gern mit ein paar kleineren "Legacy-Brüchen", ggf. mit Konverterassistent. Einfaches Portieren von alt auf neu ist zwar echt wertvoll, langfristig, vor allem mit der ein oder anderen Paradigmenverschiebung, handelt man sich so aber doch einiges an krüppeligem Ballast ein, der u.U. auch ein angestaubtes "Feeling" begünstigt.
Im Zweifel muss sogar mal ein neuer Name her. Wenn ich in meinem ehemaligen Uni/FH-Umfeld von Delphi sprach, waren die meisten schon völlig baff, dass es objektorientiert ist :shock: - ja, sehr viele davon auch Professoren/Referenten. Folgerung: Viele, auch (und vielleicht sogar gerade) im akademischen Umfeld, bringen Delphi mit TP5 in Zusammenhang, denken es wäre alt und seit 20 Jahren überholt, und würdigen es nichtmal eines zweiten Blickes. Daher formuliere ich einfach mal ganz schwammig: Ich wünsche mir für "Neopascal" ein frischeres Image =)

[stahli]

"NeoPascal" klingt gut. Vielleicht kauft Dir Emaba die Namensrechte ab? :-D

In die NET-Richtung sollte es m.E. nicht gehen. Natives Win32 bzw. Win64 sollte auf jeden Fall der Weg bleiben. Wer für NET entwickeln will, wird eh auf C# oder Prism setzen. Entsprechend sollte auch die Sprache Pascal selbst erhalten bleiben.

Aber eine Generalüberholung von Delphi (in welchen Bereichen im Detail auch immer) würde ich befürworten und dafür auf eine Aufwärtskompatibilität verzichten. Insbesondere auch eine neue VCL ohne Altlasten wäre wünschenswert.

Die IDE ist jedoch weitestgehend perfekt. Da wünsche ich mir nichts grundlegend anderes.