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

[Robotiker]

Zitat:

Zitat von stahli (Beitrag 1102071)

In die NET-Richtung sollte es m.E. nicht gehen. Natives Win32 bzw. Win64 sollte auf jeden Fall der Weg bleiben.

Ja, sehe ich auch so. Auch weil bei Microsoft in letzter Zeit das Pendel wieder in Richtung native Entwicklung umschlägt. Die Mannstärke in der C++ Entwicklung wurde dort offenbar in den letzten Monaten hochgefahren.
http://www.zdnet.com/blog/microsoft/...e_skin;content

Zitat:

Zitat von stahli (Beitrag 1102071)

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.

Ein Vorteil von Delphi ist ja die große Verfügbarkeit an Komponenten. Eine neue inkompatible Sprache würde da erstmal bei Null anfangen, da haben auch andere so ihre Probleme (Google Go, D, ...).

[mkinzler]

Die Abwärtskompatibilität war immer die Stärke von delphi. An dieser sollte man imho nicht rütteln.

[himitsu]

Zitat:

Zu blöd das Du den Fehler nicht gemeldet hast,

Zu blöd, daß der Fehler schon vor mir gemeldet wurde und sich dennoch in all den Jahren nichts getan hat.
Auch wenn ich gerade den anderen Report nicht mehr wiederfinde.

PS: "Commodore" war mal so für 2008 geplant ... mit 64 Bit-Compiler, wegen dem uralten Commodore 64

[Ralf Kaiser]

Hallo,

was ich mir wünschen würde wär eine einfachere Verwaltung von Projekteinstellungen in grossen Projektgruppen. Also z.B. einfach mal für alle im Projektmanager markierten Projekte die Optimierung ein/ausschalten.

Mit den unterschiedlichen Build-Konfigurationen ist das zwar schon einfecher geworden als vorher aber man muss teilweise, wenn man keine passenden Konfiguration verfügbar hat, doch jedes Projekt einer Projektgruppe anfassen wenn man global eine Einstellung ändern will.

Ciao,
Ralf

[himitsu]

Ich fänd es praktisch, wenn man z.B. die FinalBuilder-Projekte direkt als Projektgruppe in Delphi nutzen könnte.
Und daß dann die Projekt-Einstellungen im FinalBuilder mit denen vom Delphi 100% identisch wären.
Und auch da sollte man dann (so wie vom Vorgänger schon genannt) mehreres leicht umstellen können, bzw. via Befehl ein anderes Profil auswählen können.
(was Delphi nicht kann, dass könnte ja als deaktiviertes Dummy-Projekt in dieser Gruppe angezeigt werden ... bei XML isses ja egal, ob man alles versteht)

Aber genial wäre es, wenn man das dann auch noch komplett in der IDE laufen lassen könnte.

[Ralf Kaiser]

Noch ne "Wahnvorstellung":

Ich würde gerne beliebige Datenquellen an beliebige Controls zum Darstellen oder bearbeiten binden können.

Unter "Datenquellen" stelle ich mir dabei vor:

• Datenbanktabellen
• Queries
• Informationen aus z.B. XML-Dateien
• Delphi-Datenstrukturen (Listen, Collections, Arrays usw)

Diese Informationen sollten einfach an beliebige Controls (also nicht DBGrid, sondern einfach nur Grid) zu binden sein.

(Unter .NET geht das ja sehr gut.) In Delphi würde dabei natürlich eine gehörige Dosis RTTI im Hintergrund werkeln müssen.

[mschaefer]

Hört sich so an,

als ob die Standard-Controls ganz einfach verschwinden, nur noch DataSetControls in Delphi verbleiben und DataSetListe als Grundlage für Memos, StringGrid und StringList dienen sollen ? Oder jede Componente hat einen Anschluss an eine MemIni?

[implementation]

Quark - es geht darum, dass die Standard-Controls auch die Möglichkeit bekommen, z.B. mit Datenbanktabellen zu interagieren und man dazu keine speziellen DB-Controls mehr braucht.
Kurz gesagt: Mehr Funktionalität für die Standard-Controls, dann können die DB-Controls abgeschafft werden.

Es geht aber nicht nur um DBs - auch andere Datenquellen wie Stringlists, Variablen, Dateistrukturen usw. sollen auch als Datenquelle zu gebrauchen sein.

So verstehe ich das.

[mschaefer]

Quark ist gesund!

wegen mir auch so, die Sache ist jedenfalls gut. Die meisten meiner abgeleiteten Controls haben MemIni-Anschluss, aber das ist natürlich nicht so flexibel. Das dürfte die VCL aber deutlich durchrütteln.

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1102079)

Die Abwärtskompatibilität war immer die Stärke von delphi. An dieser sollte man imho nicht rütteln.

Fluch und Segen zugleich. Ich stimme dennoch zu und würd es auch begrüßen, wenn manch einer mal ne Sekunde das Gehirn anschalten würde, wenn mal wieder etwas nicht funktioniert und er überlegt, ob das eventuell wegen Abwärtskompatibilität oder fehlendem GC ein Problem wäre oder zumindest wegen erhöhtem Implementierungsaufwands vorerst vom Delphi Team zurückgestellt ist.

Was ich mir wünsche:

• parametrisierte Methoden in Interfaces
• Co- und Contravarianz für Generics
• Laufzeiterzeugung von generischen Typen
• property references
• bessere Kompatibilität von Methodenpointern, Events und anonymen Methoden
• native Unterstützung von Multicast Events
• Databinding
• copy operator, Standard Konstruktor und Destruktor für Records
• support für Expression trees
• weniger Schmerzen beim Implementieren des System.IEnumerable<T> Interfaces und Einführung dieses in der Generics.Collections unit.

P.S.: Wenn ich mir die Liste so anschaue... eventuell sollte ich einfach zu Delphi Prism wechseln :mrgreen: