Abstrakte Wikipedia/Prägenerisches Funktionsmodell

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Abstract Wikipedia/Pre-generic function model and the translation is 100% complete.
Diese Seite ist historisch und beschreibt nicht die aktuelle Situation. Siehe f:Wikifunctions:Funktionsmodell für die aktuelle Version des Funktionsmodells.

Abstrakte Wikipedia über Mailingliste Abstrakte Wikipedia auf IRC Wikifunctions auf Telegram Wikifunctions auf Mastodon Wikifunctions auf Twitter Wikifunctions auf Facebook Wikifunctions auf Youtube Website von Wikifunctions Translate

Das aktuelle Funktionsmodell sieht das Funktionsmodell von Wikifunctions erst für den Zeitraum vor, in dem wir den Start des Wikis planen. Insbesondere wird davon ausgegangen, dass wir bereits ziemlich funktionsfähig sind und über die Fähigkeit verfügen, Funktionen, Funktionsaufrufe, Komposition und generische Typen auszuführen. Diese werden aber erst mit Phase ζ (zeta) verfügbar sein. Dies erschwert derzeit die Implementierung von Aufgaben in den früheren Phasen, da wir nicht-generische Versionen zentraler Typen spontan bereitstellen müssen.

(Es ist sogar noch schlimmer: In Wirklichkeit ist das Funktionsmodell ein seltsamer Hybrid zwischen dem Freigabefunktionsmodell und dem vorgenerischen Modell; mit dieser Neufassung wollen wir beide Teile bereinigen, beginnend mit der Definition des vorgenerischen Funktionsmodells.)

Um diese Hürde zu überwinden, stellen wir hier eine vereinfachte Version des vollständigen Funktionsmodells zur Verfügung, die als Überbrückungslösung gedacht ist, bis die generischen Funktionen verfügbar sind.

Ein genereller Unterschied besteht darin, dass ohne die generischen Funktionen der Bedarf an lokalen Schlüsseln stark vermindert ist. Das ganze Funktionsmodell geht also davon aus, dass wir keine lokalen Schlüssel haben, oder dass wir sie bei der Normalisierung loswerden können. Dies wird nicht mehr möglich sein, sobald wir generische Funktionen haben.

"Kein Unterschied" in der folgenden Liste bedeutet, dass dieser Typ im prägenerischen Modell und im endgültigen Funktionsmodell gleich ist.

Beachte, dass die ZIDs nicht endgültig sind. Die Diskussion läuft hier.

Z1/Objekt (Z4/Typ)

  • Z1K1/type (Z4/Type)

Kein Unterschied

Z2/Persistentes Objekt (Z4/Typ)

  • Z2K1/id (Z6/String)
  • Z2K2/value (Z1/Object)
  • Z2K3/label (Z12/Multilingual text)
  • Z2K4/aliases (Z32/Multilingual set)
  • Z2K5/description (Z12/Multilingual text)


Kein Unterschied

Z3/Schlüssel (Z4/Typ)

  • Z3K1/value type (Z4/Type)
  • Z3K2/key id (Z6/String)
  • Z3K3/label (Z12/Multilingual text)

Kein Unterschied

Z4/Typ (Z4/Typ)

  • Z4K1/identity (Z4/Type)
  • Z4K2/keys (Z10/List)
  • Z4K3/validator (Z8/Function)

Z4K2 sollte eine Z10/Liste von Z3/Schlüsseln erwarten, aber das ist noch nicht möglich. Also erwartet es nur eine Z10/Liste.

Z4K3 sollte eine Z8/Funktion erwarten, die eine einzelne Eingabe vom Typ Z1/Objekt annimmt und eine Z10/Liste von Z5/Fehler zurückgibt, aber das ist noch nicht möglich, also ist es nur Z8/Funktion.

Z5/Fehler (Z4/Typ)

  • Z5K1/error type (Z50/Error type)
  • Z5K2/error value (Z1/Any)

Vielleicht kein Unterschied?

Z6/String (Z4/Typ)

  • Z6K1/string value (Z6/String)

Kein Unterschied

Z7/Funktionsaufruf (Z4/Typ)

  • Z7K1/function (Z8/Function)
  • Others based on Z8/Function

Dies wird sich erheblich ändern. In der vorgenerischen Version ist dies ein Z4/Typ, dessen Instanzen ein völlig anderes Verhalten haben als die Instanzen anderer Typen: Die Schlüssel werden nicht durch den Z4/Typ, sondern durch die Z8/Funktion definiert. Dies erfordert in der vorgenerischen Welt eine besondere Behandlung. Für die post-generische Welt erhoffen wir uns eine einheitliche Behandlung. Siehe die Diskussion hier.

Z8/Funktion (Z4/Typ)

  • Z8K1/arguments (Z10/List)
  • Z8K2/return type (Z4/Type)
  • Z8K3/testers (Z10/List)
  • Z8K4/implementations (Z10/List)
  • Z8K5/identity (Z8/Function)

Dies wird sich erheblich ändern. In der vorgenerischen Version ist dies ein Z4/Typ und dieser wird später zu einer Z8/Funktion, die grundsätzlich die vorgegebenen Schlüssel hat. Z8K1/Argumente sollten eine Z10/Liste mit Z17/Argumentdeklaration sein (offen). Z8K3 und Z8K4 sollten eine Z10/Liste mit Z20/Tester bzw. Z14/Implementation mit der angegebenen Z8/Funktion als Argument sein. Muss vollständig spezifiziert werden.

Z9/Referenz (Z4/Typ)

  • Z9K1/reference ID (Z6/String)

Kein Unterschied

Z10/Liste (Z4/Typ)

  • Z10K1/head (Z1/Object)
  • Z10K2/tail (Z10/List)

Dies wird der klassische generische Z4/Typ sein. In der vorgenerischen Version erhält es ein beliebiges Z1/Objekt als Wert und hat dann eine Z10/Liste als Fortsetzung. In der post-generischen Welt wird dies zu einer Z8/Funktion mit einem einzigen Argument vom Typ Z4/Typ, die einen Z4/Typ (die parametrierte Liste) zurückgibt, dessen Typ für den Kopf der angegebene Z4/Typ ist und dessen Typ für den Schwanz eine Z10/Liste ist, die mit demselben Typ parametriert ist.

Z11/Monolingualer Text (Z4/Typ)

  • Z11K1/language (Z60/Language)
  • Z11K2/text (Z6/String)

Kein Unterschied

Z12/Multilingualer Text (Z4/Typ)

  • Z12K1/texts (Z10/List)

Der Typ von Z12K1 sollte eine Z10/Liste von Z11/Monolinguale Texte werden.

Z14/Implementation (Z4/Typ)

  • Z14K1/function (Z8/Function)
  • Z14K2/composition (Z1/Any)
  • Z14K3/code (Z16/Code)
  • Z14K4/built in (Z6/String)

Dieser sollte die Funktion als Argument nehmen. Muss neu überdacht werden.

Z16/Code (Z4/Typ)

  • Z16K1/language (Z61/Programming language)
  • Z16K2/code (Z6/String)
  • Z16K3/signature (Z10/List)

Die Signatur wird eine Z10/Liste von Z4/Typen sein. Das wird nur im generischen Modell benötigt: Der einzige Grund für eine Signatur, die von der in der Definition getrennt ist, ist, dass wir die Werte vor der Ausführung der Funktion möglicherweise nicht auswerten müssen.

Z17/Argumentdeklaration

  • Z17K1/argument type (Z4/Type)
  • Z17K2/key id (Z6/String)
  • Z17K3/label (Z12/Multilingual text)

Kein Unterschied. Aber muss es das überhaupt geben oder kann es auch nur ein Z3/Schlüssel sein?

Z18/Argumentreferenz (Z4/Typ)

  • Z18K1/key id (Z6/String)

Kein Unterschied

Z20/Tester (Z4/Typ)

  • Z20K1/function (Z8/Function)
  • Z20K2/call (Z7/Function call)
  • Z20K3/result validation (Z7/Function call)

Z21/Einheit (Z4/Typ)

  • (keine Schlüssel)

Kein Unterschied

Z22/Paar (Z4/Typ)

  • Z22K1/first (Z1/Object)
  • Z22K2/second (Z1/Object)

Dies wird auch generisch sein.

Z23/Nichts (Z4/Typ)

  • (keine Schlüssel)

kein Unterschied

Z31/MonoLingualStringSet (Z4/Typ)

  • Z31K1/language (Z60/Sprache)
  • Z31K2/stringset (Z10/Liste)

Z31K2/stringset ist eine Z10/Liste mit Z6/Strings.

Z32/MultiLingualStringSet (Z4/Typ)

  • Z21K1/stringsets (Z10/Liste)

Z32K2/stringset ist eine Z10/Liste mit Z31/MonoLingualStringSets.

Z39/Schlüsselreferenz (Z4/Typ)

  • Z39K1/reference (Z6/String)

Kein Unterschied

Z40/Boolean (Z4/Typ)

  • Z40K1/identity (Z40/Boolean)

Kein Unterschied

Z50/Fehlertyp (Z4/Typ)

  • Z50K1/keys (Z10/List)
  • Z50K2/...: Etwas, das dies in eine Zeichenkette mit den Schlüsseln umwandelt. Dies wird später hinzugefügt.

Dies wird sich ändern. Die Z50K1 wird eine Z10/Liste von Z3/Schlüsseln sein, und, was noch wichtiger ist, dies würde eine Funktion werden, die einen Z4/Typ erzeugt.

Z60/Sprache (Z4/Typ)

  • Z60K1/code (Z6/String)
  • Z60K2/code aliases (Z10/List)

Kein Unterschied

Z61/Programmiersprache (Z4/Typ)

  • Z61K1/code (Z6/String)

Kein Unterschied

Z70/Vereinigung (Z4/Typ)

Existiert nicht im vorgenerischen Modell.

Z80/Byte (Z4/Typ)

  • Z80K1/value (Z6/String)

kein Unterschied

Z86/Codepunkt (Z4/Typ)

  • Z86K1/value (Z6/String)

Kein Unterschied

Z99/Zitat (Z4/Typ)

  • Z99K1/quotation (Z1/Object)

Kein Unterschied

Siehe auch