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

[himitsu]

Zitat:

Geht leider nicht, wenn GExprets installiert ist.

Bei uns geht es auch.
* Eine Delphi-Installation auf dem Server und mehrere Bernutzer eingelogt, geht ohne Probleme.
* Aber mehrmals Starten, bei einem Benutzer, bemängelte GExprets, da es seine Einstellungsdateien nicht ordentlich "sharen" kann.
Solange man aber nichts an den Einstellungen ändern, wörend es mehrfach geöffnet ist, gibt es keine merklichen Probleme.

[mquadrat]

Ablösung des BPL-Schnickschnack wäre natürlich toll.

Und was die Operatoren angeht fände ich ein += und ein ++ schon nett.

Und ein automatisches Umwandeln von int nach string für Ausgaben wäre auch praktisch.

[himitsu]

++ wäre mir wieder etwas zuviel C, in meinem "schönen" Delphi. :stupid:

Zitat:

Und ein automatisches Umwandeln von int nach string für Ausgaben wäre auch praktisch.

Wenn du einen integerkompatiblen Typen nimmst, welcher über Operatoren nach String umwandelt oder wenn die Ausgabefunktion

Delphi-Quellcode:

Variant

,

Delphi-Quellcode:

Array of Const

oder überladene Parameter nutzt,
dann kann man das doch auch jetzt schon?

Überall und ständig eine automatische Umwandlung spricht etwas gegen die stengen Typprüfungen in Delphi.

[geskill]

Zitat:

Zitat von mquadrat (Beitrag 1101946)

Ablösung des BPL-Schnickschnack wäre natürlich toll.

Gerade diesen "Schnickschnack" finde ich super, weil dann kann ich alle Komponenten in eine einzige BPL packen und dann meinem Programm und den Unmengen an Bibliotheken sagen die sollen doch bitte die benötigen Controls, Funktionen und weiß der Geier aus dieser BPL nehmen. Somit bleibt mein Projekt klein, weil nicht jede Bibliothek 1 MB groß ist.

Ich würde mich insbesondere über dieses Konstrukt in Delphi freuen:

Delphi-Quellcode:

with Stringlist := TStringlist.Create() do

irgendwo im QC findet sich das auch...

[DeddyH]

Zitat:

Zitat von geskill (Beitrag 1101961)

Ich würde mich insbesondere über dieses Konstrukt in Delphi freuen:

Delphi-Quellcode:

with Stringlist := TStringlist.Create() do

Wo ist da der Sinn? Du weist einer Variablen eine neue Instanz zu, brauchst die Variable aber im Anschluss eigentlich gar nicht mehr, weil Du durch das With ja direkt auf die Properties und Methoden zugreifen kannst.

Delphi-Quellcode:

with TStringlist.Create do

geht ja bereits (auch wenn das nicht ganz ungefährlich ist).

[implementation]

Ganz einfach: Man gibt der Variable damit gleichzeitig einen Namen. Stell dir folgendes vor:

Delphi-Quellcode:

with TStringList.Create do
begin
  TuWas;
  TuWasAnderes;
  Form2.Caption := 'Blabla';
  Form2.Uebergebe( { Was soll hier hin? } );
  TuWasAnderes;
  TuWas;
end;

with Stringlist := TStringList.Create do
begin
  ...
  Form2.Uebergebe(Stringlist);
  ...
end;

Wobei ich es noch schöner fände, wenn man die Variable gleich inline auch deklarieren kann:

Delphi-Quellcode:

with var StringList: TStringList := TStringList.Create do

Genauso in einer For-Schleife:

Delphi-Quellcode:

for var i: Integer := 0 to 100 do

[EDIT] Auch wenn das natürlich irgendwie Vergewaltigung unseres schönen Pascals wäre ...

[DeddyH]

Das geht jetzt aber sehr in Richtung C/C++/C#. Und was Du vorhast, bekommst Du mit einer Zeile mehr ja auch hin.

[himitsu]

Jupp, eine Namensvergabe für With wäre schon was,
aber was auch schön wäre, das wäre sowas wie Self für With.

__FUNCTION__, __LINE__, __UNIT__ und untypisierte CONST/VAR-Parameter, welcher aber die TypeInfos automatisch mit übergeben.

Und den Namespace "parent"

Delphi-Quellcode:

type 
  C = class 
    X: Integer;
    procedure M;
  end;

var 
  X: Integer;
  O: C;

procedure P;
begin
  C.X := X;
end;

procedure C.M;
begin
  Self.X := {unit}.X;
  // was ist aber, wenn ich den Unitnamen nicht direkt angeben will?
  // hier nimmt man ja sonst auch Self und nicht sowas wie das bekannte Form1 :wall:
end;

Zitat:

Delphi-Quellcode:

with var StringList: TStringList := TStringList.Create do

Gut, es gab schon einzwei Fälle, wo ich mir sowas mal gewünscht hatte, aber insgesamt bin ich doch schon froh, daß es sowas nicht gibt.
So gibt es eben 3 feste Stellen (lokal, in Klassen und global), wo Variablen deklariert sind und man weiß, wo man suchen muß/kann.

[DeddyH]

Na gut, wenn schon with, dann aber eins ohne Verwechslungsgefahr. Ich bin beileibe kein Freund von Basic, aber dort ist das eindeutig besser gelöst: ein Punkt vor der Property kennzeichnet, dass es sich um das mit with verbundene Objekt handelt.

[Elvis]

Zitat:

Zitat von DeddyH (Beitrag 1101977)

Na gut, wenn schon with, dann aber eins ohne Verwechslungsgefahr. Ich bin beileibe kein Freund von Basic, aber dort ist das eindeutig besser gelöst: ein Punkt vor der Property kennzeichnet, dass es sich um das mit with verbundene Objekt handelt.

Und Imp schlug vor es so wie in Oxygene zu machen. Dann gibt es keinen komischen Punkt, sondern einen richtigen Bezeichner.

In dem Kontext wäre natürlich auch Oxygenes "using" angebracht, und 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)
"Using" wäre dann wie Imps "with" aber würde ein try-finally erzeugen und am Ende Free ausführen.

Delphi-Quellcode:

procedure SomeClass.Miep;
begin
  using trööt := new TStringList() do
  begin
    trööt.Add('abc');
    trööt.Xyz();
  end;
end;

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.
Was bringen einem solche Features, und der Großteil des Codes, den man anschauen muss sieht immer noch so abscheulich aus?

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

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

[Ralf Kaiser]

Zitat:

Zitat von implementation (Beitrag 1102121)

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.

Und das verstehst du absolut richtig! :wink:

In .NET kann man z.B. eine Liste von Objekten eines bestimmten Typs erstellen (z.B. eine Liste von TPerson) und diese ganz einfach zur Darstellung an ein Control binden. Ein Grid würde dann für alle enthaltenen Tpersonen jeweils den Namen, Vornamen und das Alter in Spalten anzeigen und das ohne, dass man dafür irgendwelche speziellen Controls benötigt.

Die dazu nötigen Interfaces werden in .NET schon sehr früh in der Klassenhierachie definiert, sodass sich fast alles so darstellen/behandeln lässt-

Und etwas ähnliche würde ich mir für kommende VCL-Versionen wünschen (na ja, hier im Thread waren ja auch "Wünsche" und "Wahnvorstellungen" erlaubt! :wink:)

[mschaefer]

Ja dafür müsste Embracadero wahrscheinlich das komplette Delphi-Praxis-Community-Team für ein Jahr beschäftigen . . .

[stahli]

... Andererseits, wenn Stevie mal so nebenbei eine Databinding-Lösung "aus dem Ärmel schüttelt" und selbst ich eine Möglichkeit gefunden habe, Referenzen auf meine freigegebenen Objekte automatisch auf nil zu setzen, so einiges sollte schon lösbar sein.

[FredlFesl]

Also Leute, mit 'Published' geht das doch sowieso Eins-Fix-Drei.

[Stevie]

Zitat:

Zitat von FredlFesl (Beitrag 1102130)

Also Leute, mit 'Published' geht das doch sowieso Eins-Fix-Drei.

Ja, sicher, mit published wird auch automatisch der Wert aus dem Control in die Property des gebundenen Objekts übertragen ... oh halt, wird sie nicht.

[FredlFesl]

Witzbold. Mit 'published' Eigenschaften kann ich das aber Eins-Fix-Drei erledigen.
Kann mir nicht vorstellen, das Du wirklich so borniert bist.

[stahli]

..[/Sarkasmus][Sachlichkeit]...

[Stevie]

Zitat:

Zitat von FredlFesl (Beitrag 1102139)

Witzbold. Mit 'published' Eigenschaften kann ich das aber Eins-Fix-Drei erledigen.
Kann mir nicht vorstellen, das Du wirklich so borniert bist.

Wenn ich borniert wäre, hätt ich bestimmt nicht die bislang (zumindest mir bekannte) umfangreichste Databinding library für die VCL geschrieben - sogar ohne 'published'. 8-)
Also: erst informieren, dann mitreden, hier war die Rede von einer nativen Databinding Unterstützung der VCL ohne die Notwendigkeit, selber was zu schreiben.

[Ralf Kaiser]

Zitat:

Zitat von Stevie (Beitrag 1102142)

Wenn ich borniert wäre, hätt ich bestimmt nicht die bislang (zumindest mir bekannte) umfangreichste Databinding library für die VCL geschrieben - sogar ohne 'published'. 8-)

Welche Library wäre das? Kannst du mal weitere Infos geben?

[stahli]

Da hast Du...