EasyLINQ, eine generische Liste die einfache SQL Befehle ausführt

[Phoenix]

Zitat:

Zitat von Stevie (Beitrag 1122246)

Barry schrieb schon an einigen Stellen, welche Probleme sie mit Lambdas aktuell haben, z.B. hier.

Naja, "aktuell" ist relativ. Das Post war von 2008 ;)
Aber es stimmt: Für vollständige Type Inference braucht man einen Multipass Compiler, und Delphi ist historisch nunmal ein Single-Pass Compiler (was nicht heisst, dass der Compiler zwangsläufig alles mehrfach durchgehen muss, aber an manchen Stellen ist das eben nötig).

[Stevie]

Zitat:

Zitat von Phoenix (Beitrag 1122249)

Zitat:

Zitat von Stevie (Beitrag 1122246)

Barry schrieb schon an einigen Stellen, welche Probleme sie mit Lambdas aktuell haben, z.B. hier.

Naja, "aktuell" ist relativ. Das Post war von 2008 ;)
Aber es stimmt: Für vollständige Type Inference braucht man einen Multipass Compiler, und Delphi ist historisch nunmal ein Single-Pass Compiler (was nicht heisst, dass der Compiler zwangsläufig alles mehrfach durchgehen muss, aber an manchen Stellen ist das eben nötig).

Ich schrieb nicht, dass der Post aktuell ist, sondern das Problem, und da sich in der Hinsicht nix getan hat, isses immernoch aktuell ;)

[Daniela.S]

Neues Update...

- Parser überarbeitet
- Update Befehl hinzugefügt
- Unterklassen werden unterstützt

[Elvis]

Mein Delphi 2010 stoplert über 2 Sachen:

In Calculator.Calulate benutzt du eine (scheinend globale?) Variable namens FormatSettings.
Die gibt es bei mir nicht.
Ich habe es so gelöst.

Delphi-Quellcode:

  FormatSettings : TFormatSettings;
begin
  fValid := True;
  if Length( s ) <3 then begin
    fValid := False;
    Exit( 0 );
    end;

  SysUtils.GetLocaleFormatSettings(LOCALE_SYSTEM_DEFAULT, FormatSettings);

Der Call füür getlocale ist sicherlich weniger teuer, als sowas statisch für die Laufzeit der App zu cachen. (Da du ja dann keine Änderungen der Settings bemerken würdest)


Dann benutzt du an 2 Stellen einen Safecast ("as") auf TObject, den mag mein Delphi auch nicht.
Ich musst hier einen Hard-Cast machen:

Delphi-Quellcode:

//TLinQ<T>.Remove
TObject(fItems[index]).Free;
//TLinQ<T>.Clear;
    for item in fItems do TObject(item).Free;

Da du in beiden Fällen vorher die RTTI fragst, ob T eine Klasse ist, musst du hier auch nicht befürchten, dass du den Kater auf TEichhörnchen wurschtelst... :-)

Rein vom API-Design her, finde ich es ein wenig zu einvernehmend die Unit LinQ und die Klasse TLinq zu nennen.
Solche doch sehr offensichtlichen Namen sollten dem Delphi-Team vorbehalten bleiben.
Falls Delphi irgendwann sowas kriegt, könnten Unit- oder Type-Name mit dem kollidieren, was Borlemb aus dem Hut zaubert.
Oder es kollidiert mit den sicherlich vorhandenen anderen LinQ-Workarounds für Delphi.
Oh, und "SELECT" als Prefix ist anscheinend gar nicht nötig. Vllt einfach aus den Beispielen rausnehmen.
Wirkt komisch, wenn man keine Property-liste angeben kann.

Ansonsten ist das sicherlich eine nette Bereicherung für so manchen. :-)

[Daniela.S]

Wie schon geschrieben habe ich es noch nicht auf Delphi 2010 probiert. Derzeit verwende ich die Unit in einem XE Projekt. Aber ich stürze mich gleich nachher darauf :wink:

FormatSettings gibt es erst ab Delphi XE. Beinhaltet von da an den DecimalSeparator.

Am Namen wird es nicht liegen, kann ich gerne ändern. Ich bezweifle jedoch dass Linq in absehbarer Zukunft erscheinen wird. Es wurde 2005 schon mal angekündigt. Was hat sich getan? Nix :| Nichtmal auf Roadmaps konnte ich das bisher erblicken. Solange Lambda, Extension Methods und Type Inference per Default nicht in irgendeiner Art implementiert sind, steht auch die grundlegende Technik dahinter nicht zur Verfügung. Bei XE2 muss ich erst schauen was sich in diesem Bereich getan hat.

Großes Problem ist auch, dass es bei Generics in Delphi 2010 sehr viele Fehler gab. XE hat mir hier auch schon einige Interne Fehler geworfen. XE2 ist da schon um einiges besser.

Und die Rtti funktioniert mit Records scheinbar immer noch nicht.

Tante Edit sagt: Achja, Select ist Optional, kann man um der Syntax-Willen schreiben...

[Elvis]

Zitat:

Zitat von Daniela.S (Beitrag 1123711)

Wie schon geschrieben habe ich es noch nicht auf Delphi 2010 probiert. Derzeit verwende ich die Unit in einem XE Projekt. Aber ich stürze mich gleich nachher darauf :wink:

FormatSettings gibt es erst ab Delphi XE. Beinhaltet von da an den DecimalSeparator.

Ist das eine Funktion oder eine globale Variable?
Letzteres wäre schon ganz schön Kac*e und sollte den Borlembern um die Ohren geworfen werden.
Aber wenn ich FormatSettings als lokale Variable nehme und in Calculate mit der Änderung oben besetze fluppt es.

Zitat:

Und die Rtti funktioniert mit Records scheinbar immer noch nicht.

Dein Bleistift läuft bei D2010 nach meinen Änderungen, wenn man Record auswählt.

[Uwe Raabe]

Zitat:

Zitat von Elvis (Beitrag 1123719)

Ist das eine Funktion oder eine globale Variable?
Letzteres wäre schon ganz schön Kac*e und sollte den Borlembern um die Ohren geworfen werden.

Es ist eine globale Variable! Damit es abwärtskompatibel bleibt, ging es wohl auch nicht anders. Faktisch zeigt FormatSettings.DecimalSeparator und DecimalSeparator so auf denselben Speicherbereich. Ändere ich das eine, ändert sich auch das andere (wäre sonst auch tödlich).

Grundsätzlich sollte man aber immer ein eigenes FormatSettings kreieren, dann klappts auch mit dem Multithreading.

[Daniela.S]

Man kann (oder zumindest habe ich es bis jetzt noch nicht geschafft) in Records zu schreiben. GetValue legt immer eine neue Kopie an. Auch mit TValue.MakeWithoutCopy funktioniert es nicht. Bislang habe ich im Internet auch keine Informationen gefunden woran es liegt.

Ja FormatSettings ist Global. Ein Record das auch verschiedene Funktionen zur Verfügung stellt. Soweit ich gesehen habe kein SingleTon und auch nicht Threadsicher.

Ich lade gleich das Update hoch... eine Minute noch...

[Daniela.S]

Update ist Online

[DeddyH]

Das waren aber 12 Minuten :mrgreen: