Neuester QC-Lacher

[Union]

Am 25. September hatte ich nach einer Diskussion mit Marco Cantù ein QC erstellt wegen TCustomAttributes. Den Testfall hatte ich zum Nachvollziehen unter "Steps" geposted.

Es endete wie eigentlich immer - "As Designed".

Auf meine Rückfrage wo dies denn dokumentiert sei erhielt ich nie Antwort. Jetzt habe ich bei der Kontrolle des QC-Status nochmal nachgeschaut und siehe da - die Dokumentation wurde am 2. Oktober dahingehend ergänzt. Durch PASTEN des QC inkl. Source.

Leider hat nicht mal das geklappt, die Hälfte der Testprozedur wurde nicht mit kopiert, so dass sich der Sinn (The following code snippet demonstrates this ...) dem Betrachter nicht so ganz erschließt.

So kann man natürlich auch nachträglich Tatsachen schaffen :evil:

[jfheins]

Schön dass das jetzt dokumentiert wurde, andererseits gehörst du natürlich geteert wenn du ein Attribut ohne Suffix benennst ;-)

Mit deinem "Expected result" stimme ich auch nicht überein. Schöner wäre da imho ein Compiler-Fehler. Zum Beispiel sowas:

Zitat:

Fehler: "MyTest" kann "ConsoleTest.MyTest" oder "ConsoleTest.MyTestAttribute" sein. Verwenden Sie entweder "@MyTest" oder "MyTestAttribute". Program.cs

Von mir aus dürfte der aber auch schon kommen, wenn man eine Klasse von (TCustom)Attribute ableitet, aber das Suffix nicht benutzt. Wir lernen daraus: Sich an Namenskonventionen halten, sonst erlebt man böse Überraschungen :P

[Daniel]

Kein Zweifel, dass dieses Verhalten von Anfang an so hätte dokumentiert werden müssen. Auch hier hat man offenbar gedacht, "das machen die bei C# so, das machen wir auch". Bei einer derart streng typisierten Sprache wie Delphi erschließt sich mir nicht, warum man dem Compiler ausgerechnet hier Spielraum lässt.

[Der schöne Günther]

Dass man das "Attribute"-Postfix auch weglassen kann wusste ich zwar, dass eins in diesem Fall komplett verdeckt werden würde habe ich aber auch nicht eingeplant.

Eine offizielle Namenskonvention kann ich im Wiki-Artikel aber nicht finden. Der dann angegebene Codeschnipsel ist auch etwas unverständlich abgeschnitten. Aber insgesamt finde ich das auch keinen "Lacher". Natürlich hat man hier oft Probleme, ernst genommen zu werden, aber insgesamt sagt der Wiki-Artikel doch jetzt alles was man wissen muss, oder?

[Elvis]

Der Fehler sollte wenn, dann erst im Falle einer Kollision erzeugt werden.
Also wenn ein Attribute ohne Suffix genutzt wird, und es ein anderes im Scope gibt, welches auch passen könnte.

Wenn C# als Beispiel Pate stand, dann lief das was schief: C# würde das nämlich nicht zulassen. (C# lässt generell keine Namenskollisionen zu)

[jfheins]

Zitat:

Zitat von Elvis (Beitrag 1234683)

Der Fehler sollte wenn, dann erst im Falle einer Kollision erzeugt werden.
Also wenn ein Attribute ohne Suffix genutzt wird, und es ein anderes im Scope gibt, welches auch passen könnte.

Wenn C# als Beispiel Pate stand, dann lief das was schief: C# würde das nämlich nicht zulassen. (C# lässt generell keine Namenskollisionen zu)

Naja, die C# Fehlermeldung habe ich ja oben gepostet: Der Fehler kommt bei der Verwendung des Attributes. Deklariert man zwei Attribute (einmal "MyTestAttribute", und "MyTest") so compiliert das noch wunderbar. Erst beim Versuch, es mit [MyTest] zu verwenden schlägt der Compiler mit o.g. Fehlermeldung an. Und in diesem Fall kann man dann die Mehrdeutigkeit manuell auflösen, indem man z.B. [@MyTest] schreibt. (Habe diese Verwendung des @ noch nicht gesehen...)

Aber ja, es ist sehr wahrscheinlich dass hier C# als Pate stand - dann hätte man aber das Feature auch ruhig etwas besser kopieren können inkl. der Compilerfehler.