Eine Anmerkung zur Syntax

Die in dieser PEP vorgeschlagenen Syntaxvorschläge sind vorläufig und sollten als Strohmänner betrachtet werden. Die notwendigen Teile, von denen diese PEP abhängt – nämlich die Klassendefinitionssyntax von PEP 3115 und Klassendekoratoren von PEP 3129 – werden noch formalisiert und können sich ändern. Funktionsnamen werden natürlich langen Debatten über die „Bikeshedding“-Diskussionen unterliegen.

Statische Rollenzuweisung

Beginnen wir mit der Definition der Klassen Tree und Dog.

class Tree(Vegetable):

  def bark(self):
    return self.is_rough()


class Dog(Animal):

  def bark(self):
    return self.goes_ruff()

Obwohl beide eine bark()-Methode mit der gleichen Signatur implementieren, tun sie sich wild unterschiedliche Dinge. Wir brauchen eine Möglichkeit, das, was wir erwarten, zu differenzieren. Die Abhängigkeit von Vererbung und ein einfacher isinstance()-Test schränkt die Code-Wiederverwendung ein und/oder zwingt jede hundeartige Klasse, von Dog zu erben, unabhängig davon, ob dies sinnvoll ist. Mal sehen, ob Rollen helfen können.

@perform_role(Doglike)
class Dog(Animal):
  ...

@perform_role(Treelike)
class Tree(Vegetable):
  ...

@perform_role(SitThere)
class Rock(Mineral):
  ...

Wir verwenden Klassendekoratoren aus PEP 3129, um einer Klasse eine bestimmte Rolle oder Rollen zuzuweisen. Client-Code kann nun überprüfen, ob ein eingehendes Objekt die Rolle Doglike ausführt, was es ermöglicht, auch Instanzen von Wolf, LaughingHyena und Aibo [1] zu verarbeiten.

Rollen können durch normale Vererbung zusammengesetzt werden.

@perform_role(Guard, MummysLittleDarling)
class GermanShepherd(Dog):

  def guard(self, the_precious):
    while True:
      if intruder_near(the_precious):
        self.growl()

  def get_petted(self):
    self.swallow_pride()

Hier führen Instanzen von GermanShepherd drei Rollen aus: Guard und MummysLittleDarling werden direkt zugewiesen, während Doglike von Dog geerbt wird.

Rollen zur Laufzeit zuweisen

Rollen können auch zur Laufzeit zugewiesen werden, indem die durch Dekoratoren bereitgestellte syntaktische Zuckerung entpackt wird.

Nehmen wir an, wir importieren eine Robot-Klasse aus einem anderen Modul, und da wir wissen, dass Robot bereits unsere Guard-Schnittstelle implementiert, möchten wir, dass sie auch gut mit Wachschutz-bezogenem Code funktioniert.

>>> perform(Guard)(Robot)

Dies tritt sofort in Kraft und wirkt sich auf alle Instanzen von Robot aus.

Fragen zu Rollen stellen

Nur weil wir unserer Roboterarmee gesagt haben, dass sie Wachen sind, möchten wir sie gelegentlich überprüfen und sicherstellen, dass sie noch bei ihrer Aufgabe sind.

>>> performs(our_robot, Guard)
True

Was ist mit diesem einen Roboter dort drüben?

>>> performs(that_robot_over_there, Guard)
True

Die Funktion performs() wird verwendet, um zu fragen, ob ein gegebenes Objekt eine gegebene Rolle erfüllt. Sie kann jedoch nicht verwendet werden, um einer Klasse zu fragen, ob ihre Instanzen eine Rolle erfüllen.

>>> performs(Robot, Guard)
False

Dies liegt daran, dass die Klasse Robot nicht mit einer Instanz von Robot austauschbar ist.

Leere Rollen

Rollen werden wie eine normale Klasse definiert, verwenden aber die Metaklasse Role.

class Doglike(metaclass=Role):
  ...

Metaklassen werden verwendet, um anzuzeigen, dass Doglike eine Role ist, genauso wie 5 eine int ist und tuple ein type ist.

Rollen durch Vererbung zusammensetzen

Rollen können von anderen Rollen erben; dies hat den Effekt, sie zu komponieren. Hier führen Instanzen von Dog sowohl die Rollen Doglike als auch FourLegs aus.

class FourLegs(metaclass=Role):
  pass

class Doglike(FourLegs, Carnivor):
  pass

@perform_role(Doglike)
class Dog(Mammal):
  pass

Konkrete Methoden erfordern

Bisher haben wir nur leere Rollen definiert – nicht sehr nützliche Dinge. Lassen Sie uns nun verlangen, dass alle Klassen, die behaupten, die Rolle Doglike zu erfüllen, eine Methode bark() definieren.

class Doglike(FourLegs):

  def bark(self):
    pass

Keine Dekoratoren sind erforderlich, um die Methode als „abstrakt“ zu kennzeichnen, und die Methode wird nie aufgerufen, was bedeutet, dass jeder Code, den sie enthält (falls vorhanden), irrelevant ist. Rollen bieten *nur* abstrakte Methoden; konkrete Standardimplementierungen sind anderen, besser geeigneten Mechanismen wie Mixins überlassen.

Sobald Sie eine Rolle definiert und eine Klasse behauptet hat, diese Rolle zu erfüllen, ist es unerlässlich, dass dieser Anspruch überprüft wird. Hier hat der Programmierer eine der von der Rolle geforderten Methoden falsch geschrieben.

@perform_role(FourLegs)
class Horse(Mammal):

  def run_like_teh_wind(self)
    ...

Dies führt dazu, dass das Rollensystem eine Ausnahme auslöst und sich darüber beschwert, dass Ihnen eine Methode run_like_the_wind() fehlt. Das Rollensystem führt diese Prüfungen durch, sobald eine Klasse als Erfüllende einer bestimmten Rolle gekennzeichnet wird.

Konkrete Methoden müssen exakt mit der von der Rolle geforderten Signatur übereinstimmen. Hier haben wir versucht, unsere Rolle durch die Definition einer konkreten Version von bark() zu erfüllen, aber wir haben das Ziel ein wenig verfehlt.

@perform_role(Doglike)
class Coyote(Mammal):

  def bark(self, target=moon):
    pass

Die Signatur dieser Methode stimmt nicht exakt mit dem überein, was die Rolle Doglike erwartete, so dass das Rollensystem ein wenig Aufruhr verursacht.

Instanzen andere Rollen als ihre Klasse ausführen lassen

Perl 6 erlaubt es Instanzen, andere Rollen als ihre Klasse auszuführen. Diese Änderungen sind auf die einzelne Instanz beschränkt und wirken sich nicht auf andere Instanzen der Klasse aus. Zum Beispiel:

my_elf = Elf()
my_elf.goes_on_quest()
my_elf.becomes_evil()
now_performs(my_elf, Thieving) # Only this one elf is a thief
my_elf.steals(["purses", "candy", "kisses"])

In Perl 6 geschieht dies durch die Erstellung einer anonymen Klasse, die vom ursprünglichen Elternteil der Instanz erbt und die zusätzlichen Rollen ausführt. Dies ist in Python 3 möglich, ob es wünschenswert ist, ist jedoch eine andere Frage.

Die Aufnahme dieser Funktion würde es natürlich wesentlich einfacher machen, die Werke von Charles Dickens in Python auszudrücken.

>>> from literature import role, BildungsRoman
>>> from dickens import Urchin, Gentleman
>>>
>>> with BildungsRoman() as OliverTwist:
...   mr_brownlow = Gentleman()
...   oliver, artful_dodger = Urchin(), Urchin()
...   now_performs(artful_dodger, [role.Thief, role.Scoundrel])
...
...   oliver.has_adventures_with(ArtfulDodger)
...   mr_brownlow.adopt_orphan(oliver)
...   now_performs(oliver, role.RichWard)

Attribute erfordern

Neal Norwitz hat die Möglichkeit gefordert, Aussagen über die Anwesenheit von Attributen mit demselben Mechanismus zu machen, der zum Erfordern von Methoden verwendet wird. Da Rollen zur Zeit der Klassendefinition wirksam werden und da die überwiegende Mehrheit der Attribute zur Laufzeit durch die __init__()-Methode einer Klasse definiert wird, scheint es keine gute Möglichkeit zu geben, Attribute gleichzeitig mit Methoden zu überprüfen.

Es kann dennoch wünschenswert sein, nicht erzwungene Attribute in die Rollendefinition aufzunehmen, und sei es nur zu Dokumentationszwecken.

Rollen von Rollen

Unter den vorgeschlagenen Semantiken ist es möglich, dass Rollen eigene Rollen haben.

@perform_role(Y)
class X(metaclass=Role):
  ...

Dies ist zwar möglich, aber bedeutungslos, da Rollen im Allgemeinen nicht instanziiert werden. Es gab einige Offline-Diskussionen darüber, diesem Ausdruck Bedeutung zu verleihen, aber bisher sind keine guten Ideen aufgetaucht.

class_performs()

Es ist derzeit nicht möglich, eine Klasse zu fragen, ob ihre Instanzen eine bestimmte Rolle ausführen. Es kann wünschenswert sein, ein Analogon zu performs() bereitzustellen, so dass

>>> isinstance(my_dwarf, Dwarf)
True
>>> performs(my_dwarf, Surly)
True
>>> performs(Dwarf, Surly)
False
>>> class_performs(Dwarf, Surly)
True

Schönere dynamische Rollenzuweisung

Ein früher Entwurf dieser PEP enthielt einen separaten Mechanismus zur dynamischen Zuweisung einer Rolle zu einer Klasse. Dies wurde geschrieben

>>> now_perform(Dwarf, GoldMiner)

Diese Funktionalität existiert bereits durch das Entpacken der durch Dekoratoren bereitgestellten syntaktischen Zuckerung.

>>> perform_role(GoldMiner)(Dwarf)

Die Frage ist, ob dynamische Rollenzuweisung wichtig genug ist, um eine dedizierte Schreibweise zu rechtfertigen.

Syntaxunterstützung

Obwohl die in dieser PEP dargelegten Formulierungen so konzipiert sind, dass das Rollensystem als eigenständiges Paket ausgeliefert werden kann, kann es wünschenswert sein, spezielle Syntax für die Definition, Zuweisung und Abfrage von Rollen hinzuzufügen. Ein Beispiel könnte ein Schlüsselwort role sein, das übersetzt wird.

class MyRole(metaclass=Role):
  ...

in

role MyRole:
  ...

Die Zuweisung einer Rolle könnte die in PEP 3115 vorgeschlagenen Argumente für die Klassendefinition nutzen.

class MyClass(performs=MyRole):
  ...