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:

Zitat von Shivan

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

Ok, auch ne Möglichkeit.

Zitat:

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:

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:

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". :mrgreen: Viel zu fehleranfällig. Ausnahme : Entwicklung für zu verkaufende Komponenten. Das muss man aber nicht unbedingt als Beispiel nehmen. :stupid:

[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.

[Sanchez]

Zitat:

Zitat von Hansa

Eben. Die verwendet man selber so im eigenen Programm nicht. Weil : "abstrakter Fehler". :mrgreen: Viel zu fehleranfällig.

Ich verwende durchaus abstrakte Methoden. Das schöne dran ist, dass der Compiler meckert, wenn man eine Klasse instanziiert wo eine abstrakte Methode nicht überschrieben wurde. Es sei denn, man verwendet eine Factory um seine Objekte zu erzeugen.

[mkinzler]

Wenn man auf alle Features verzichten würde, weil sie falsch angewendet zu Fehlern führen würden, würden nicht viele übrig bleiben.

[alzaimar]

Zitat:

Zitat von mkinzler

Wenn man auf alle Features verzichten würde, weil sie falsch angewendet zu Fehlern führen würden, würden nicht viele übrig bleiben.

'nicht viele'? Welche denn? :zwinker:

Ich halte so ein Tool wirklich für sinnvoll, wenn das Team entschieden hat, in JEDER überschriebenen Methode zumindest als Bemerkung ein 'Inherited' stehen zu haben. Das ist eine Disziplin, die man so ruhig akzeptieren kann. Insofern würde ich so ein Tool selbst zusammenfrickeln. Es muss kein richtiger Parser sein, sondern nur ein Mustererkenner...

[jottkaerr]

Zitat:

Zitat von Sanchez

Ich verwende durchaus abstrakte Methoden. Das schöne dran ist, dass der Compiler meckert, wenn man eine Klasse instanziiert wo eine abstrakte Methode nicht überschrieben wurde. Es sei denn, man verwendet eine Factory um seine Objekte zu erzeugen.

Ich schreibe bei Klassen, die von abstrakten Basisklassen erben und von denen ich über eine Factory Objekte erstellen möchte, immer

Delphi-Quellcode:

implementation
  if False then
  begin
    TMyConcreteClass.Create({ passende Dummy-Parameter }).Free;
    { ... }
  end;
end.

ans Ende der Unit. Leider erhält man auch damit keine Meldung, welche abstrakte Methode noch nicht überschrieben wurde. Für diesen Zweck hätte ich gerne ein Tool -- kennt jemand eins?

jkr