[Python-de] super() vs. self.__class__

Rainer Fischbach fischbach at ecs-gmbh.de
Tue Sep 10 21:08:20 EDT 2002


>
>Eventuell kann man Methoden nicht kooperativ realisieren. Das geht
>nur, wenn man für jede Komponente Pre- und Post-Bedingungen
>formulieren kann. Für "save" funktioniert das recht gut.
>
Pre- und Post-Bedingungen kann man im Prinzip immer formulieren. Damit die
kooperativen Methoden funktionieren, müssen ganz bestimmte Bedingungen,
nämlich die Subtyp-Relation zwischen den Methodendefinitionen in der
abgeleiteten Klasse und der Basisklasse erfüllt sein: Wenn C und C' jeweils
m definieren und C' von C abgeleitet ist, dann muss die Precondition von
C.m die Precondition von C'.m und die Postcondition von C'.m die
Postcondition von C.m implizieren, was auch bedeutet, dass für jeden
formalen Parameter von C'.m die Menge der zulässigen Argumente eine
Obermenge der zulässigen Argumente des betreffenden formalen Parameters von
C.m und die Menge der Resultatwerte von C.m eine Obermenge der
Resultatwerte von C'.m sein muss.

Genau das ist in typischer objektorienter Software oft nicht erfüllt. Ich
hab ja durchaus zugegeben, dass das alles korrekt funktionieren kann. Ich
finde nur problematisch, dass hier ein neuer Mechanismus auftaucht, der in
einem Fall (super), wo in der oo-Tradition bisher ganz klar eine statische
Methodenselektion gemeint war, eine dynamische Selektion einführt, die
zudem noch die aparte Eigenschaft hat, dass sie nicht nur zum effektiven
Aufruf der Methode aus einer abgeleiteten Klasse (wie im 'oo-Normalfall'
abhängig vom dynamischen Typ des Zielobjekts) sondern sogar der Methode aus
einer unverwandten, parallelen Klasse führen kann. Das ist eine neue Form
von nichtlokalem Effekt, der zu sehr schwer aufspürbaren Fehlern führen
kann. Die Semantik dieses Features ist eben nicht mehr modular. Vor allem
fehlen in 'Unifying types and classes' eindeutige Hinweise auf die
Bedingungen, unter denen dies nur funktioniert.

>> Ich hab langsam das Gefühl, dass der Featurismus, der sich in den letzten
>> Python-Releases breitmacht, zu einem Durcheinander von ad-hoc-Lösungen
>> führt, deren Konsequenz niemend mehr richtig durchschaut.
>
>Kooperative Methoden sind durchaus nicht ad-hoc, sondern
>wissenschaftlich fundiert und in der Literatur belegt.
>
naja, Belege lassen sich in der Literatur für alles mögliche finden, auch
für Rezepte, die z. B. zu Typfehlern führen (siehe etwa die 1. Auflage von
OOSC). Nicht, dass man keine neuen Mechanismen ausprobieren sollte, doch
ich kann mir durchaus alternative Weisen vorstellen, um zu garantieren,
dass eine Methode in einem bestimmten Zusammenhang nur einmal aufgerufen
wird. Am sichersten wäre doch ein Mechanismus, bei dem man die betreffende
Methode selbst entsprechend deklariert.

     
    Rainer Fischbach
______________________________________________________

    ECS
    Engineering Consulting & Solutions GmbH
    Muehlstrasse 3
    D-92318  Neumarkt

    Phone:               +49 (0)9181 - 4764-84
    Fax:                 +49 (0)9181 - 4764-50
    Mobile:              +49 (0)171  - 41 41 570
    e-mail:              fischbach at ecs-gmbh.de
    WWW:                 http://www.ecs-gmbh.de
______________________________________________________






More information about the Python-de mailing list