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

[USchuster]

Zitat:

Zitat von Stevie (Beitrag 1102124)

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:

Zitat von Stevie (Beitrag 1102124)

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

Warum?

[himitsu]

Zitat:

Zitat von USchuster (Beitrag 1102165)

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:

Zitat von himitsu (Beitrag 1102080)

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.

Mein Report mit Deinem Problem ist vom Januar 2011. Wenn es tatsächlich einen anderen Report gibt, dann her mit der Nummer.

Zitat:

Zitat von himitsu (Beitrag 1102080)

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

Das alte Commodore sollte zuerst am Jahresende 2008 (Winter 2008) nach Delphi Tiburón (erste Hälfte 2008) und C++Builder Barracuda (Mitte 2008) erscheinen. Tiburón und Barracuda sind zusammen in Q3/2008 erschienen als Delphi/C++Builder 2009 und zu diesem Zeitpunkt war Commodore bereits auf Mitte 2009 verschoben wurden. Die danach getroffene Entscheidung Compilerteile neuzuschreiben kann ich nur begrüßen - einen Delphi 2009 Compiler + 64-bit hätte ich nicht haben wollen. Das aktuelle Commodore Projekt hat nichts mehr mit alten Commodore Projekt zu tun, da der Delphi Teil des alten Commodore Projekts jetzt Bestandteil von Pulsar ist und der C++ Teil von Projekt Wheelhouse.

Ich glaube vor Jahren war sogar mal 2006/2007 im Gespräch. Das bringt uns keinen Schritt weiter. Hoffen wir das es dieses Jahr erscheint und wenn ich David I richtig verstanden habe, dann müsste XE2 ja Ende August/Anfang September erscheinen.

[USchuster]

Zitat:

Zitat von himitsu (Beitrag 1102168)

Zitat:

Zitat von USchuster (Beitrag 1102165)

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:

Zitat von USchuster (Beitrag 1102165)

Zitat:

Zitat von Stevie (Beitrag 1102124)

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.

[mkinzler]

Konstruktoren sind aber auch Klassenmethoden. Ruft man sie später direkt auf einen Objek auf, werden diese erneut ausgeführt, ohne dass eine neue Instanz erzeugt wid

[FredlFesl]

Zitat:

Zitat von Stevie (Beitrag 1102142)

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

Bravoooo!.
Aber auch bornierte Menschen können programmieren. Also hat das Eine nichts mit dem Anderen zu tun.

Dessenungeachtet habe ich ja gerade geschrieben, das ich mich mir *NICHT* (negierung, verneinung) vorstellen kann, das Du so borniert bist, wie Du dich dargestellt hast. Weiterhin habe ich auch nicht behauptet, das es nur mit 'published' Eigenschaften geht.

Also: erst lesen, dann verstehen, und erst dann mitreden.

Nebenbei: Mir ist deine Arbeit nicht unbekannt, das nur mal so am Rande, Stevie. ;-)

[Matze]

Hört bitte auf, euch gegenseitig anzugreifen. Das gilt speziell für dich, FredlFesl.

Hier geht es darum, Wünsche für kommende Delphi-Versionen zu äußern und sachlich darüber zu diskutieren. Also macht das bitte. Es wäre doch schade, wenn sich das Thema so verläuft und daraufhin geschlossen werden muss.

[Daniel]

Thema schließen wäre eine Option, ich habe aber auch kein Problem damit, einzelne Personen von der Teilnahme auszuschließen.

Bleibt sachlich oder lasst es bleiben.

[mkinzler]

Ich hoffe es geht auch ohne den "Holzhammer" :wink:

[mquadrat]

Ein ARM-Compiler soll frühestens 2013 kommen? Da es wohl keinen Legacy-Support in Win 8 ARM geben wird, ist das irgendwie.. doof. Andererseits wird es ja auch mehr Wintel Tablets in 2011/2012 geben. Sollte also n icht so das Problem geben. Außer natürlich man entwickelt für den Consumer-Bereich..

Ich hätte gerne ein vollständiges Application-Framework, inkl. ORM, DataBinding und allem anderen Schnickschnack mit IDE-Support natürlich.



OffTopic: Gibt's eigentlich schon eine Feature-Liste für XE2?

[himitsu]

Zitat:

Zitat von mquadrat (Beitrag 1102379)

OffTopic: Gibt's eigentlich schon eine Feature-Liste für XE2?

Solche Listen wurden von Jahr zu Jahr kürzer und seit einer Weile gibt es sowas offiziell garnicht mehr,
denn man hat mitbekommen, daß wenn etwas darin steht, was dann doch noch nicht enthalten ist, dann gibt es zuviele Proteste seitens der Kunden.
Also sagt man lieber nichts mehr ... dann kann auch keiner mehr meckern. :angle2:

[mkinzler]

Zudem ist ja noch eine Weile zur Veröffentlichung

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1102379)

OffTopic: Gibt's eigentlich schon eine Feature-Liste für XE2?

Es wurden ja schon ein paar Sachen veröffentlicht. Zum Beispiel die 64-Bit und Mac OS Unterstützung.

Dass es da keine Liste gibt, dürfte mehrere Gründe haben. Unter anderem psychologische. Denn wenn schon alle Features vorher bekannt werden, wird wieder das Maul zerrissen, dass das alles unrealistisch ist und wenn dann die Version herauskommt, wird sich mokiert, dass ja nichts wirklich Neues dabei ist. (Weil es eben schon länger bekannt ist.)

Zu den kommenden Features an sich möchte bzw. darf ich nichts weiter sagen, deshalb zitiere ich einmal fachlich unkommentiert diese Liste aus der Agenda der nächsten Delphi-Tage:

Zitat:

• Vorhandene Bibliotheken
• GUI Design
• 2D vs 3D
• Datenbindung
• Konkreter Einsatz auf Mac OSX
• Ausblick Linux

Ich denke konkret ein Punkt, von dem ich bisher dachte, dass er noch nicht veröffentlicht hätte werden dürfen, steht hier auf der Wunschliste bei jemandem. ;-)

// EDIT:

Zitat:

Zitat von Luckie (Beitrag 1101321)

Aber was ich mir noch wünschen würde, wieder so eine ausführliche Hilfe wie zu D6/D7 Zeiten. Schön mit Codebeispielen und einer funktionierenden Suche. Also irgendwas, was die Bezeichnung Hilfe auch verdient. Unter 21006 kämpfe ich manchmal mehr mit der Hilfe, als mit meinem Code. Und dann sage ich mir, läuft da doch irgendwas falsch.

Die Hilfe hat sich ja schon von D7 zu XE deutlich verbessert. Beispiele finde ich persönlich gar nicht so wichtig, das mag stimmen, dass es da weniger gibt. Viel wichtiger fände ich, dass alle Befehle ordentlich beschrieben sind (was ja leider noch nicht überall der Fall ist, wenn auch meistens).

Und es sind ja auch diverse sehr ausführliche Anleitungen zum Beispiel zu DataSnap hinzugekommen.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1102394)

Zu den kommenden Features an sich möchte bzw. darf ich nichts weiter sagen, deshalb zitiere ich einmal fachlich unkommentiert diese Liste aus der Agenda der nächsten Delphi-Tage:

Zitat:

• Vorhandene Bibliotheken
• GUI Design
• 2D vs 3D
• Datenbindung
• Konkreter Einsatz auf Mac OSX
• Ausblick Linux

Ich denke konkret ein Punkt, von dem ich bisher dachte, dass er noch nicht veröffentlicht hätte werden dürfen, steht hier auf der Wunschliste bei jemandem. ;-)

Bleibt abzuwarten, a) ob das neue GUI Framework (auf Basis oder zumindest auf dem Wissen von VGScene aufbauend) schon produktiv tauglich ist und b) ob Datenbinding nur dort funktioniert, oder auch in die VCL Einzug nimmt (was ja ohne Probleme funktionieren sollte, ich würds ansatzweise so wie mit den Gestures machen) und c) wie weit die Fähigkeit, Datenbindung vorzunehmen, geht (Stichwort: Variable an Edit binden)

Auf jeden Fall bin ich schon ziemlich gespannt auf XE2 - denn imo bietet Databinding eine unerahnte (zumindest für die, die es noch nicht live erlebt haben) Flexibilität bei der Entwicklung.

Zitat:

Zitat von jaenicke (Beitrag 1102394)

Die Hilfe hat sich ja schon von D7 zu XE deutlich verbessert. Beispiele finde ich persönlich gar nicht so wichtig, das mag stimmen, dass es da weniger gibt. Viel wichtiger fände ich, dass alle Befehle ordentlich beschrieben sind (was ja leider noch nicht überall der Fall ist, wenn auch meistens).

Wäre nur noch zu wünschen, dass man sich von diesem besch...eidenen Microsoft Document Explorer verabschiedet.

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1102394)

Die Hilfe hat sich ja schon von D7 zu XE deutlich verbessert. Beispiele finde ich persönlich gar nicht so wichtig, das mag stimmen, dass es da weniger gibt. Viel wichtiger fände ich, dass alle Befehle ordentlich beschrieben sind (was ja leider noch nicht überall der Fall ist, wenn auch meistens).

Das werde ich demnächst sehen!

Von D2006 sich zu verbessern, ist ja wahrhaftig keine Kunst, von D7, das wäre nicht schlecht.
(D2006/ADO da muß man wohl dankbar sein, daß es überhaupt etwas gibt, Vollständigkeit und Fehlerarmut davon träumt man).

Gruß
K-H

[Assarbad]

Einen ordentlichen Präprozessor der diesen Namen auch verdient. Alternativ einen Mechanismus mithilfe dessen ich einen Präprozessor zwischenschalten kann, ohne gleich Kopfstände veranstalten zu müssen.

[mschaefer]

Wenn man von Pascal ausgeht, könnte man eine online Konvertierung zu C++ und zurück per IDE-Shortcut realisieren . . .

[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

Delphi-Quellcode:

myString.Upper();

ein

Delphi-Quellcode:

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. :stupid:

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1102683)

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

Schonmal geschaut, wie man extension methods in C# schreibt? :stupid:

[himitsu]

ihhh C ... sowas guck ich mir nich an :stupid:

[Elvis]

Zitat:

Zitat von Stevie (Beitrag 1102675)

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

Delphi-Quellcode:

myString.Upper();

ein

Delphi-Quellcode:

Upper(myString);

bastelt (oh Wunder, das ist genau das, was in C# bei den extension methods passiert).

Diese ganzen XYZ-Helper, haben ja gegenüber Ex-Methods nur den Vorteil, dass man damit Properties abbilden kann.
Ansonsten fand' ich es unglaublich ernüchternd, dass CodeGear tatsächlich so blödsinnig war, und Record-Helper einführte, anstatt einfach einfach nur noch "Helper for IrgendeinenTypenWieZumBleistiftInteger" zuzulassen.
Tat richtig weh, wenn jemand so einen riesigen Hebel hat und mit sowenig Aufwand soviel erreichen könnte, nur um sich dann (dank des offenkundig nicht vorhandenen Anspruchs) mit der primitivsten und sinnlosesten Lösung zufrieden zu geben. ("record helper" neben dem vorher schon existierenden "class helper")

[implementation]

Zitat:

Zitat von Elvis (Beitrag 1102801)

Diese ganzen XYZ-Helper, haben ja gegenüber Ex-Methods nur den Vorteil, dass man damit Properties abbilden kann.

Nö, noch einen: Man kann damit Bugs fixen.
In C# hat eine echte Methode immer Vorrang vor den Extension Methods, d.h. wenn es eine Methode gibt namens "HansWurst" und eine Extension Method, die ebenfalls "HansWurst" heißt, wird die Extension Method niemals aufgerufen, sondern jedesmal die echte Methode. Selbst, wenn sie verschiedene Signaturen haben.
In Delphi haben die Helper den Vorrang, d.h. man hat eine Methode A und der Helper hat ebenfalls eine Methode A. Wenn jetzt irgendwo im Code Instanz.A aufgerufen wird, kommt die Helper-Methode zum Einsatz.

[Elvis]

Zitat:

Zitat von implementation (Beitrag 1102810)

Zitat:

Zitat von Elvis (Beitrag 1102801)

Diese ganzen XYZ-Helper, haben ja gegenüber Ex-Methods nur den Vorteil, dass man damit Properties abbilden kann.

Nö, noch einen: Man kann damit Bugs fixen.
In C# hat eine echte Methode immer Vorrang vor den Extension Methods, d.h. wenn es eine Methode gibt namens "HansWurst" und eine Extension Method, die ebenfalls "HansWurst" heißt, wird die Extension Method niemals aufgerufen, sondern jedesmal die echte Methode. Selbst, wenn sie verschiedene Signaturen haben.

Das stimmt nicht! Ich kann mich erinnern, dass Oxygene sich so verhalten hat (kA ob es das nohc tut).
Aber nicht C#. Dort gewinnt die tatsächliche Methode nur wenn die Signatur gleich ist oder besser passt.

Code:

static void Miep(this Sample instance, object untypedValue)
{
   instance.Miep((int)untypedValue);
   instance.SetByExMethod = true;
}

class Sample
{
   public int Value { get; private set; }

   public bool SetByExMethod { get; set; }

   public void Miep(int newValue)
   {
      Value = newValue;
      SetByExMethod = false;
   }
}

static void Main()
{
   var s = new Sample();

   s.Miep(untypedValue: 1);
   Debug.Assert(s.Value == 1 && s.SetByExMethod);

   s.Miep(2);
   Debug.Assert(s.Value == 2 && !s.SetByExMethod);

   s.Miep((Object)3);
   Debug.Assert(s.Value == 3 && s.SetByExMethod);
}

[implementation]

Zitat:

Zitat von Elvis (Beitrag 1102850)

]Das stimmt nicht! Ich kann mich erinnern, dass Oxygene sich so verhalten hat (kA ob es das nohc tut).
Aber nicht C#. Dort gewinnt die tatsächliche Methode nur wenn die Signatur gleich ist oder besser passt.

Ist mein Gedächtnis so schlecht? Ich ahbe auch mehrere Monate mit C# gearbeitet und mich dauernd eben darüber geärgert :gruebel:
Irgendwie kann ich mir auch nicht vorstellen, dass Oxygene und C# da unterschiedlich verfahren.

[edit]
Du hast Recht, hab nochmal nachgeguckt.

An meiner Grundaussage rüttelt das jedoch nichts:
C#: echte Methoden Vorrang
Delphi: Helper-Methoden Vorrang

[mquadrat]

Ahh ich hätte da noch was:

Alle Dreingaben / Zusatzsoftware / Stückwerk mit in den Hauptinstaller packen. Bis man den ganzen Kram einzeln deinstalliert hat, hat man einen Bart :D

Und ein schnelleres EDN.

[himitsu]

Den Installer sollte man sowieso mal überarbeiten ... du willst nicht wissen, was für ein Schrott da drinnen enthalten ist.
(wer den Schock für's Leben haben will, der brauch sich diesen nur mal ansehn)

[mquadrat]

Gilt funktionierendes Error Insight eigentlich als Traum oder Wahnvorstellung? :?:

[DeddyH]

Beides :)

[mquadrat]

Das hatte ich befürchtet :lol:

[jbg]

Zitat:

Zitat von mquadrat (Beitrag 1102899)

Das hatte ich befürchtet :lol:

In XE hat sich da doch einiges getan. Man darf nur nicht kompilieren, da dann die Parser-Symbole der Reihe nach ausfallen.

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1102897)

Gilt funktionierendes Error Insight eigentlich als Traum oder Wahnvorstellung? :?:

In XE habe ich damit kaum noch Probleme. Wenn ich eine Unit neu hinzufüge oder so wird schon mal einiges als falsch markiert, aber wenn ich die Datei oder das Projekt schließe und wieder öffne, ist es wieder in Ordnung.

// EDIT:
Die größten Probleme habe ich im Grunde mit Compilerdefines usw., die in der IDE nicht korrekt ausgewertet werden. Denn das führt dazu, dass die Codenavigation usw. nicht funktioniert...

[stahli]

Eine Kleinigkeit aber doch sehr hilfreich:

Componentvervollständigungen (Ctrl-Shift-C) sollten nicht in Regionen erfolgen, zumindest nie in geschlossenen Regionen.
Regionen definiert/schließt man ja, um sie als Block zu behandeln und auszublenden.

Auch stört mich, dass bei der Codeformatierung (Ctrl-D) alle Regionen geöffnet werden.

[jaenicke]

Ich wär schon froh, wenn die Codeformatierung anonyme Methoden kennen würde. Wenn man eigene Zeilenumbrüche behalten lässt, gehts einigermaßen, aber nicht schön. Ich weiß nicht, ob das schon dran war das Thema. :D

[geskill]

Zitat:

Zitat von jaenicke (Beitrag 1107166)

Ich wär schon froh, wenn die Codeformatierung anonyme Methoden kennen würde. Wenn man eigene Zeilenumbrüche behalten lässt, gehts einigermaßen, aber nicht schön. Ich weiß nicht, ob das schon dran war das Thema. :D

+1

Delphi-Quellcode:

class function TApiPlugin.CMSBelongsTo(ACMSPluginPath, AWebsiteSourceCode: string): Boolean;
var
  _BelongsTo: Boolean;
  _Plugin: ICMSPlugIn;
begin
  _BelongsTo := False;
  LoadPlugin(ACMSPluginPath,
    { } procedure(var APlugin: IPlugIn)
    { } begin
    { . } if APlugin.QueryInterface(ICMSPlugIn, _Plugin) = 0 then
    { ... } try
    { ..... } _BelongsTo := _Plugin.BelongsTo(AWebsiteSourceCode);
    { ... } finally
    { ..... } _Plugin := nil;
    { ... } end;
    { } end);
  Result := _BelongsTo;
end;

Ich mach das mit den geschweiften Klammern, aber ist ein enormer Aufwand nur damit es halbwegs lesbar ist!

[himitsu]

Wäre das Leben schön, wenn man in Class-Helpern auf Konstruktoren und Destruktoren reagieren könnte *träum*
(bzw. quasi sowas wie AfterConstruction und BeforeDestruction)

Klassenvariablen kann man in Class-/Record-Helper wenigstens schonmal nutzen. :D

[Stevie]

Wie soll das bei nem Class helper gehen? Du überschreibst ja keine virtuellen Methoden damit.

[himitsu]

Nichts überschreiben oder so, einfach nur alle "Konstruktoren" der Class Helper aufrufen, nachdem AfterConstruction der Klasse ausgeführt wurde.
(in der Reihenfolge, wie die Class Helper eingebunden wurden)
Man bräuchte einfach nur dort die ganzen Class Helper durchsteppen, wo auch AfterConstruction aufgerufen wird.

Praktisch wäre das dann sogar in der umgekehrten Reihenfolge, wie beim Überschreiben (override), wo ja das zuerst ausgeführt wird, was man als Letztes in einer Ableitung deklariert wurde.

[Stevie]

Klingt für mich aber eher nach nem Workaround für schlechtes Design.
Mehr als 1 Helper gleichzeitig: ja - Verhalten von bestehenden Klassen verändern: nein