Major
Nice to have
Detail
Detail
#25759
Inkonsistente Prüf-Expressions in Command-Executability und Delete-Constraints
Die Signatur der Executabilty bei Kommandos erwartet ein boolean=true als Rückgabewert für die Ausführbarkeit.
Der Delete-Constraint an Klassen hingegen "null" als Rückgabewert für die Ausführbarkeit.
D.h. Executability für Deletekommandos: x -> if(<test>, true, #"object.delete.notAllowed")
Der gleiche delete constraint am Typ: if(<test>, null, #"object.delete.notAllowed")
Hier wäre zu überlegen, ob man die Signaturen nicht angleicht.
Die Variante mit "null" hat den Vorteil, dass man die Regel so schreiben könnte: if(!<test>, #"object.delete.notAllowed") ... weil null der implizite else-Zweig-Wert ist.
Die Variante mit true hat den Vorteil, dass man den Ausdruck <test> || #"object.delete.notAllowed" schreiben könnte... vielleicht will man beides als "ok" werten, null und true...
Die Variante mit true/false hat den Vorteil, dass sie explizit ist. Das macht es mMn für Nutzer einfacher, da sie explizit überlegen müssen, was Sache ist.
Und es ist auch näher an der natürlichen Sprache. Ausführen? Ja/Nein.
Umsetzung
Die beiden Rückgabetypen null und true werden als ausführbar interpretiert.
Das heißt der Ausdruck
x -> if(<test>, true, #"object.delete.notAllowed")
ist "äquivalent" zu
x -> if(<test>, null, #"object.delete.notAllowed")
Test
TestDeleteConstraintWithBooleanReturnType.script.xml