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

[stahli]

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

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 von stahli:

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 von stahli:

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.

[Stevie]

Zitat von mkinzler:

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

[USchuster]

Zitat von Stevie:

Was ich mir wünsche:

• weniger Schmerzen beim Implementieren des System.IEnumerable<T> Interfaces

Helfen würde wenn die Notwendigkeit für die Interface Variable/den Interface Typecast für die "for in" Schleife wegfallen würde für den Fall das IEnumerable und IEnumerable<T> in der gleichen Klasse implementiert sind. (siehe bekannter Thread IEnumerable<T> in .delphi.rtl)

QC Eintrag ist auf meiner Todo Liste.

Zitat von Stevie:

und Einführung dieses in der Generics.Collections unit.

Warum?

[himitsu]

Zitat von USchuster:

Helfen würde wenn die Notwendigkeit ...

Das Problem hier ist leider, daß jeder generische Typ quasi einen neuen Basistypen bildet und er leider keine Ableitung darstellt.
Wäre aber schön, wenn man das ändern würde.

[USchuster]

Zitat von himitsu:

Zitat von USchuster:

Helfen würde wenn die Notwendigkeit ...

Das Problem hier ist leider, daß jeder generische Typ quasi einen neuen Basistypen bildet und er leider keine Ableitung darstellt.
Wäre aber schön, wenn man das ändern würde.

Daran das in der Klassenhierarchie TBar<Integer> nicht TBar<T> als Parent hat wird sich sicher nicht ändern, da TBar<T> nicht instanziert wird. Hat TBar<T> als Vorfahren TFoo<T>, dann wird TFoo<Integer> instanziert, aber nicht TFoo<T>.

Es geht in dem noch zu erstellenden QC Eintrag darum das der Compiler erkennt das ein generischer Enumerator über das IEnumerable<T> bereitgestellt wird ohne das man die Instanz als IEnumerable<T> typecasten muss oder eine IEnumerable<T> Hilfsvariable braucht (oder einen generischen Enumerator ohne IEnumerable<T> implementiert, welcher dann nicht mit TList<T>.AddRange/InsertRange verwendet werden kann)

D.h. jetzt muss man anstatt

Delphi-Quellcode:

var
  pStream: TStream;
  pList: TMyCollection<TMemoryStream>;
begin
  pList := TMyCollection<TMemoryStream>.Create;
  for pStream in pList do
    Writeln(pStream.ClassName);

eine der beiden folgenden Varianten schreiben, wenn man nicht wie Stevie IEnumerable und IEnumerable<T> in unterschiedlichen Klassen implementiert.

Hilfsvariable:

Delphi-Quellcode:

var
  pStream: TStream;
  pList: TMyCollection<TMemoryStream>;
  pListEnum: IEnumerable<TMemoryStream>;
begin
  pList := TMyCollection<TMemoryStream>.Create;
  pListEnum := pList;
  for pStream in pListEnum do
    Writeln(pStream.ClassName);

Typecast:

Delphi-Quellcode:

var
  pStream: TStream;
  pList: TMyCollection<TMemoryStream>;
begin
  pList := TMyCollection<TMemoryStream>.Create;
  for pStream in IEnumerable<TMemoryStream>(pList) do
    Writeln(pStream.ClassName);

[Stevie]

Zitat von USchuster:

Zitat von Stevie:

und Einführung dieses in der Generics.Collections unit.

Warum?

Damit die Klassen in Generics.Collections auch kompatibel mit dem IEnumerable interface sind? Ansonsten gibts keinen Weg, IEnumerable und TEnumerable miteinander zu verknüpfen. Genau das hab ich nämlich mit meinem TEnumerableEx<T> gemacht, welches eine Ableitung von TEnumerable<T> ist und IEnumerable<T> implementiert. Und dann bekommt man dieses großartige Problem mit gleichnamigen Methoden unterschiedlicher Signatur, welches man nur lösen kann, wenn man eine von beiden umnennt.

[Stevie]

Mir fällt noch was ein:

• interface helper (aka extension methods)

Wäre sogar noch vielseitiger und imo unter der Kategorie syntactic sugar umsetzbar, indem der compiler aus myString.Upper(); ein Upper(myString); bastelt (oh Wunder, das ist genau das, was in C# bei den extension methods passiert).

[himitsu]

Nur daß dieser erste Parameter in Delphi als verstecktes Self übergeben würde.