Delphi-Quellcode:
if not (SomeEnum in SomeSet) then
// vs
if not SomeEnum in SomeSet then
NOT ist nunmal höherrangig, als IN, da führt kein drumrum.
Auch wenn man jetzt das IN vorrangig behandeln würde, wäre das keine Lösung, da sich dann Andere wieder beschweren würden, weil plötzlich was Anderes nicht mehr ginge.
Darum gings doch gerade. NamenLozer hatte geschrieben, dass er gerne sehen würde, dass z.B. ">" stärker bindet als z.B. "and". Und wenn wir da schon dabei sind, dann hätte ich gerne, dass "in" stärker bindet als "not", weil ich mir echt keine wirkliche Situation vorstellen kann, in der "(not SomeEnum) in SomeSet" Sinn hätte... aus Compilersicht ist das was wir aktuell haben vielleicht sogar die einfachere Lösung (also das "not" stärker bindet).
Zitat von
himitsu:
Es sieht zwar nicht so schön aus, aber ein &String
sollte es doch tun, oder nicht
genau, voll häßlich.
Ich weiß nichtmal, warum man STRING so behandeln mußte?
Und wenn, warum ist dann Integer, Boolean und Co. nicht auch fett?
Weil Integer, Boolean und Co. keine Schlüsselwörter sind. Der Compiler würde dich nicht davon abhalten eine eigene Funktion "Integer" zu definieren. String ist wahrscheinlich ein wegen ShortString ein Schlüsselwort:
Delphi-Quellcode:
type
String42 = String[42];
Zitat von
himitsu:
Open Tools
API ... die Schnittstelle zur
IDE Danke.
Zitat von
himitsu:
Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?
(angenommen dort sind bestimmte Typen im Record, wie z.B. Strings, dyn. Array oder Interfaces)
Delphi-Quellcode:
var
X, Y: TMyRecord;
begin << X und Y werden initialisiert (wenn dort bestimmte Typen drauf sind)
Y := X; << es wird eine Kopierfunktion aufgerufen, welche den Record kopiert
end; << es wird eine Funktion aufgerufen, welche den Record freigibt
In diesen schon vorhandenen Funktionen muß man nur noch schauen, ob in der
RTTI des Records die neuen Operatoren stehen und ruft sie dann auf.
Es gibt schon seit langem einen EDN.Eintrag von mir, aber auf mich hört ja keiner. (vorallem da es keine großen Änderungen mit sich zieht)
Die Kopierfunktion könnte aber von überladenen Zuweisungsoperatoren beeinflusst werden...
Diese Ereignisse wären aber durchaus interessant, das müsste ich mir mal im FPC anschauen, was man da machen könnte.
Gruß,
Sven