Kennt jemand ein inherited-Check-Tool?

[Shivan]

Kennt jemand ein Tool, das überprüft, ob bei Methoden, die als "override" markiert sind, auch mindestens irgendwo ein "inherited" innerhalb der Methode aufgerufen wird?

Delphi selbst zeigt das ja leider nicht an...

[Sanchez]

Ich bin mir nicht sicher, aber der Pascal Analyzer von Peganza (www.peganza.com) könnte das anzeigen. Ich habs zuhause leider nicht installiert und kann jetzt nicht nachsehen, es könnte aber vorhanden sein. Das Tool ist allerdings nicht kostenlos.

grüße,
Daniel

[alzaimar]

Es ist doch nicht verboten, den Vorgänger einer überschriebenen Methode aufzurufen...? Manchmal brauch mans, manchmal nicht. Dafür einen Analyzer würde bei meinen Projekten absolut sinnlos sein.

[inherited]

*ssssst*
Engaging full system check *miiiiiiieeeep*
Loading... please wait *büüüpüüüpüüüpüüüüpüüüü*
Finished loading, please stand by!
*in die hose lunz*
system ok! *ziiieeeep*

Spaß bei seite, schreib dir doch selber ein Tool, so schwer ist es nicht

[Sanchez]

@alzaimar: Er will ja auch rausfinden, wo er vergessen hat den Vorgänger aufzurufen.

[Shivan]

@Sanchez: Werd ich mir in dem Fall mal anschaun... vielleicht reicht ja die Trial für einen ersten komplettscan...

@alzaimar: Verboten nicht, aber ich bin jetzt schon einige Male auf die Schnauze gefallen, weil irgend ein Hiesl (ugs.) das inherited vergessen hatte. Bei uns ist das in der Regel so, dass bei override immer ein Inherited reinkommt. Falls nicht, wird trotzdem inherited reingeschrieben, aber auskommentiert + Kommentar, WARUM.
Weil wozu gibts Ableitungsmechaniken, wenn man die Parent-Logik komplett ausklammern muss? Dann stimmt doch schon was in der Architektur nicht...
Ist meine Meinung.

@inherited: Ja könnte ich selber schreiben, aber warum das Rad neu erfinden, wenn es dafür schon was gibt? Muss nicht sein. Das steigert die Produktivität nicht unbedingt

[alzaimar]

Zitat von Shivan:

Falls nicht, wird trotzdem inherited reingeschrieben, aber auskommentiert + Kommentar, WARUM.

Ok, auch ne Möglichkeit.

Zitat von Shivan:

Weil wozu gibts Ableitungsmechaniken, wenn man die Parent-Logik komplett ausklammern muss? Dann stimmt doch schon was in der Architektur nicht...
Ist meine Meinung.

Na ja. Es gibtg ja nicht nur eine Erweiterung der Funktionalität, sondern auch ein Ersetzen. Aber lass uns nicht darüber reden. Ich denke, Dein Wunsch ist doch zu exotisch, zumal Du auch den auskommentierten Inherited-Aufruf finden willst.

Deine Frage sollte eher so lauten:

>> Kennt jemand einen sauber implementierten Delphi-Parser? <<

Dann kann man sich das 1-fix-3 selber basteln.

[grenzgaenger]

Zitat von Shivan:

Weil wozu gibts Ableitungsmechaniken, wenn man die Parent-Logik komplett ausklammern muss? Dann stimmt doch schon was in der Architektur nicht...
Ist meine Meinung.

tja, dann sind etliche architekturen falsch... insbesondere, wenn abstrakte methoden definiert werden... welche eine einheitliche anwendung und ableitung ermöglichen sollen. wenn man diese dann aufrufen möchte, dann krachts... also mit inherited, kommt man da zu wunderbaren fehlermeldungen

[Hansa]

Zitat von grenzgaenger:

...tja, dann sind etliche architekturen falsch... insbesondere, wenn abstrakte methoden definiert werden...

Eben. Die verwendet man selber so im eigenen Programm nicht. Weil : "abstrakter Fehler". Viel zu fehleranfällig. Ausnahme : Entwicklung für zu verkaufende Komponenten. Das muss man aber nicht unbedingt als Beispiel nehmen.

[sx2008]

Der Aufruf von inherited ist ja nur im Konstruktor und Destruktor Pflicht.
(Eigentlich sollte der Compiler warnen, wenn im Konstruktor oder Destruktor inherited nicht aufgerufen wird.
Bei C++ wird das automatisch vom Compiler erzwungen, was aber IMHO zu wenig Freiheit bietet.
Bei Delphi gibt's zu viel Freiheit, denn man kann inherited im Destruktor auch weglassen oder an falscher Stelle aufrufen)
Man kann ja im Sourcecode nach construktor und destructor suchen und so die Fehler entdecken.