Hilfe Diskussion:Lua/Links

Title-Objekt

Auf dieser Hilfeseite ist es dringend geboten, sauber zwischen Eigenschaften eines existierenden Objekts und seinen Methoden zu unterscheiden. Der Seiteninhalt ist ein Wirrwarr aus einfachen Eigenchaften, Abfragemethoden, Objerkterzeugenden Funktionen (Konstruktoren) und sonstigen Funktionen, welche Objekte als Parameter haben, ohne selbst Methode eines Objekts zu sein.

Insbesondere sind bei den Funktionen solche, welche aus einer - ggf. nicht existierenden - Seite ein Objekt erzeugen - also Konstruktoren - klar von den Queries zu trennen.

Darüber hinaus sind auch Funktionen, welche nicht Methode eines Title-Objekts, aber keine Konstruktoren sind, klar abzusetzen. Gruß von ÅñŧóñŜûŝî (Ð) 22:49, 28. Jun. 2020 (CEST)

• „Wie unterscheidet man eine Eigenschaft von einer Methode?“
  • Kinderleicht, eine Methode ist eine Funktion und durch runde Klammern gekennzeichnet.
  • Eine Eigenschaft ist keine Funktion und hat auch keine runden Klammern.
  • Das gilt für alle Objekte aller einschlägigen Programmiersprachen.
  • Wenn konsistent gearbeitet wurde, dann erkennt man Methoden auch an dem Doppelpunkt vor dem Bezeichner; das ist aber nicht ganz durchgängig und gelegentlich auch eine Punkt-Komponente.
  • Wenn der Eintrag nicht mit mw., sondern mit einem Punkt oder Doppelpunkt beginnt, dann ist es eine Komponente des Objekts; wenn nicht, dann halt eine irgendwo anders her stammende Funktion.
  • Bisher waren die Komponenten inhaltlich-thematisch gruppiert gewesen. Das hast du jetzt zerschossen.
  • Wenn du es noch weiter ruinieren möchtest, dann würde ich empfehlen, die drei zurzeit nach Länge der resultierenden URL angeordneten localUrl() fullUrl() canonicalUrl() alphabetisch zu sortieren.
• Ein „Konstruktor“ ist keine „Methode“ , auch wenn du bei deinem Zerschmeißen der bis dahin inhaltlich korrekten Hilfeseite jetzt alle Funktionen in einen Topf geworfen hast, und auch statische Bibliotheksfunktionen ebenfalls als angebliche Objekt-Methoden unter deiner einheitlcihen Überschrift „Methoden“ zuammengedroschen hast.
  • Ein Konstruktor bildet erst ein Objekt.
  • Nachdem ein Objekt gebildet wurde, kann man dessen Felder (Eigenschaften) auslesen und dessen Methoden aufrufen, die speziell über dieses Objekt etwas näher erklären.
  • Du hattest jetzt sämtliche Konstruktoren und statische Bibliotheksfunktionen unter deiner neuen Überschrift „Methoden (Funktionen)“ mit einsortiert, während diese vor deiner Vermurksung dem Abschnitt über das Objekt vorangestellt gewesen waren.
  • Das weist nach, dass du nicht die allerleiseste Ahnung von Objekten und OOP hast.
• Wenn du keine Ahnung von der Materie hast, ist das nicht weiter schlimm. Das erwartet auch niemand. Aber wenn du keine Ahnung von den Inhalten hast, kannst du nicht einfach über Nacht losziehen und ohne Ankündigung lauter gequirlten Sondermüll in Hilfeseiten reindreschen.
• Durch Löschung der Überschrift des title-Objekts hast du dann auch gleich noch ein paar Linkziele abgeschossen.
• „wirkungsgleich“ ist „wirkungsgleich“, darüber gibt es nichts zu diskutieren und auch keine dämlichen „Überarbeiten“-Bausteine zu setzen.
  • „wirkungsgleich“ bedeutet, dass es völlig egal ist, ob du es auf die eine oder auf die andere Art machen würdest.
  • „wirkungsgleich“ bedeutet, dass genau die gleiche Wirkung erzielt wird, wenn du den dort jeweils explizit angegebenen Lua-Code aufrufen würdest, oder wenn du die Eigenschaft ausliest.
  • Das hat nichts mehr mit Hilfeseite und technischen Lua-Details zu tun, sondern mit dem Verständnis deutscher Sprache.
• Ach, übrigens, schon seit einem Jahrzehnt durchgesetzte Grundregel der Wikisyntax: Eine Definitionsliste wird niemals durch Leerzeilen unterbrochen, die Semikola bei den Definionstermen haben eine semantische Bedeutung, ein Definionsterm ist etwas anderes als ein Wort in Fettschrift, zu jedem folgenden Doppelpunkt-Ausdruck gehört ein davor stehender Definionsterm mit Semikolon. Was du wie ein blutiger Anfänger heute Nacht obendrein zerschossen hast.

--PerfektesChaos 13:08, 29. Jun. 2020 (CEST)

@PerfektesChaos: Ich weis auch, was ein Konstruktor ist (Ich programmiere gelegentlich auch objektorientiert in C++) und das ein Konstruktor keine Methode sein kann. Ich habe dieses bereits vorgefundene Durcheinander von Definitionstermen mit und ohne Klammern - das solltest du wirklich auch mal einräumen können - schlichtweg nicht mehr komplett sortiert, weil es mir zuviel wurde. Insoweit war das nicht komplett umstrukturiert. Wenn dort als Definitionsterm z. B. .rootPageTitle - ohne Klammern etc. - steht und damit als Eigenschaft dargestellt wird, dann ist für Leser nicht nachvollziehbar, wie eine angebliche "Eigenschaft" mit dem Konstruktor mw.title.makeTitle( title.namespace, title.rootText) wirkungsgleich sein kann. Ich vermute mal, dass vor .rootPageTitle sowas wie mw.title steht und dahinter ein Klammerpaar mit Parametern darin (exakt die gleichen Namen?) gehört. Sorry, aber bei allem Respekt vor deinem großen Fleiß hier: Wenn du willst, dass andere die Ergebnisse deiner Arbeit auch verstehen, dann solltest du dir die Mühe machen, die Syntax genau darzustellen. Bei derart mangelhafter Darstellung brauchst du dich nicht zu wundern, wenn andere Mühe haben, Eigenschaften und Funktionen auseinanderzuhalten! Es fehlt auch ein didaktischer Faden:

Mein Vorschlag zur didaktischen Struktur:

• Zuerst sollte das Objekt vorgestellt werden und zwar so, dass auch Autoren, denen das PME-Modell nicht so geläufig ist, verstehen, dass es ein "Abbild" einer WP-Seite darstellt. Es schadet auch nicht, wenn kurz erwähnt wird, dass zu diesem Abbild nicht nur die Eigenschaften einer Seite gehören, sondern auch Funktionen für das, was man damit machen kann (z. B. den Quelltext abfragen) und das es auch Funktionen gibt, mit denen man ein derartiges Objekt erzeugen kann, sei es mit den Parametern einer existierenden Seite oder mit neuen für eine noch nicht existente Seite.
• Anschließend sollten die Eigenschaften und Funktionen vorgestellt werden, idealerweise mit einer kompletten Quelltextzeile. Lua ist dafür bekannt, dass es auch Funktionen gibt, bei denen meist keine Zuweisung erfolgt und schlicht ein Parameter verändert wird. Man denke nur an table.insert. Es schadet also nicht, eine ganze Zuweisung darzustellen.
• Jede Funktion sollte dargestellt werden mit:
  • Was macht / bewirkt diese Funktion?
  • Welche Parameter welchen Typs braucht sie, welche optionale Par. gibt es?
  • Was gibt die Funktion zurück?
• Als Reihenfolge schlage ich vor:
  1. Die Eigenschaften des Title-Objekts: Name, Typ, Bedeutung
  2. Die Konstruktoren
  3. Die Methoden

Das Uri-Objekt sollte ähnlich erläutert werden.

Zugegeben: Das ist insgesamt viel Arbeit, aber alle wikispezifischen Features wie diese Objekte brauchen ein genaue Darstellung.

Teamarbeit mit dir ist meines Erachtens auch bei Absprache mit dir nicht leicht und das gilt auch für mich. Wir sind wohl beide Autoren, die gerne "alles aus einem Guss" haben möchten und daher lieber alleine arbeiten. Insoweit kann ich dir da nicht helfen, auch wenn ich es gerne würde. Es bleibt mir also nichts anderes übrig, als an dich zu appellieren, diese Hilfeseite auszubauen und die Autoren dort abzuholen, wo sie dir auch folgen können. Wäre super, wenn du meinen Vorschlag einbauen würdest. Gruß von ÅñŧóñŜûŝî (Ð) 21:58, 29. Jun. 2020 (CEST)

In Lua gibt es überhaupt keine „Konstruktoren“, weil es auch keine objektorientierte Sprache ist.

• Es wird nur mit den table so getan, als ob, und versucht, deren Konzeptionen in Lua nachzubilden.
• Es müsste ein Sprachkonstrukt geben:
  local myPage = new mw.title()
  • Das gibt es jedoch nicht.
  • Es gibt bei Scribunto ausschließlich normale Bibliotheksfunktionen, die hin und wieder zufällig als Ergebnis ein Objekt liefern.
  • Was dem noch am nächsten käme und dem new-Ausdruck nachgebildet wurde, ist
    local myPage = mw.title.new( text, namespace )
• Die einzige mir einfallende wirkliche Konstruktor-Funktion in der Wiki-Welt, die dem new-Konzept nahekäme, ist:
  local myDate = DateTime() in Wikipedia:Lua/Modul/DateTime/de #Bibliotheksobjekt
• Da es in Lua schon überhaupt keine Konstruktoren gibt, hat es erst recht keine Destruktoren; man kann allenfalls schreiben
  o = nil
  und damit eine mögliche Freigabe des Speicherplatzes signalisieren; ob das aber die Speicherplatzfreigabe garbage collection auf dem Wiki-Server interessieren würde und ob der nicht einfach das #invoke: bis zum Ende abarbeitet und fertig, ist denen ihre interne Angelegenheit.

Die Hilfeseite folgt der Reihenfolge, zu der ein Lua-Benutzer gezwungen ist:

1. local meineSeite = mw.title.getCurrentTitle()
2. if meineSeite:inNamespace( 12 ) then -- ich bin auf einer Hilfeseite

• Das ist die aus didaktischen Gründen von mir gewählte Abfolge:
  1. Wie komme ich zu einem Objekt?
  2. Wenn ich das Objekt habe, wie komme ich dann zu dessen Eigenschaften und Methoden?

Wenn dir die umseitige Hilfeseite nicht ausführlich genug ist, dann verwende halt mw:Extension:Scribunto/Lua reference manual #Title library

• In der gibt es allerdings null Anwendungsbeispiele; umseitig immerhin eines, das exemplarisch für jede auftretende Konstellation die Verwendung demonstriert (aber bekanntlich nur 4 Beispiele für 80 Gegenstände; nicht wie von dir begehrt 80 Beispiele, für jede Eigenschaft und Funktion ein eigenes).
• Ach ja, wie allgemein üblich, verzeichnet auch MediaWiki zuerst die Bibliotheksfunktionen, danach kommen die Eigenschaften und Methoden des title-Objekts.
• Nebenbei bemerkt sind auch dort, wie allgemein üblich, Eigenschaften und Methoden nur dadurch zu unterscheiden, dass an Methoden runde Klammern dran sind, und an Eigenschaften halt nicht. Dafür spendiere ich am Anfang wenigstens immer noch den passenden Punkt oder Doppelpunkt.

Deine „didaktischen“ Vorschläge hast du dir gerade eben aus den Fingern gesogen, um nachträglich dein Gemurkse irgendwie aussehen zu lassen, als ob du dir was dabei gedacht hättest.

• Ich schreibe auch C++ und Java seit den späten 1980ern und Mitte der 1990er Jahre, über Jahrzehnte, heutzutage seltener.
• In beiden Sprachen gibt es eine übliche Reihenfolge, sowohl was die Deklaration in den Quellcodes angeht, wie auch deren Wiedergabe in den Dokumentationen:
  1. Konstante
  2. Konstruktoren
  3. Destruktoren
  4. Felder der Instanz (hier bei uns Eigenschaften)
     • Öffentliche eigene Felder einer Instanz bekanntzugeben gilt in manchen Welten als Programmierfehler, auch wenn das syntaktisch möglich ist.
  5. Methoden
  6. Operatoren
  7. Ausnahmen bzw. Events
• Das gilt genauso in JavaScript; auf dieser Seite unter Tausenden findest du:
  1. unter der Überschrift Syntax den Ausdruck für den Konstruktor;
  2. unter der Überschrift Eigenschaften die Felder;
  3. unter der Überschrift Methoden ebenjene, sofern vorhanden, und das einheitlich.
• Weil oben von DateTime die Rede war, habe ich einfach mal nach constructor DateTime gekugelt und eine von Millionen standardisierter Javadoc-Resultate gefunden; mindestens siehst du dort schon mal die Konstruktoren an allererster Stelle, erst danach dann die Methoden unter ihrer eigenen Überschrift (und nicht wie bei dir alles unter einer Funktionen-Überschrift zusammengeschmissen); das ist mit C++ auch nicht anders.
• Ach ja, und was deine Behauptungen über Klammern und Nicht-Klammern angeht: Einfach mal dieses Verzeichnis lesen; anhand der Klammern und der Groß- und Kleinschreibung ist es schon überflüssig, method oder variable oder class dranzuschreiben, ergibt sich von selbst:
  • class beginnt mit Großbuchstabe, ist Camelcase, hat keine Klammern;
  • constructor beginnt mit Großbuchstabe, ist Camelcase, hat Klammern;
  • method beginnt mit Kleinbuchstabe, ist ggf. Camelcase wenn lang, hat Klammern;
  • variable beginnt mit Kleinbuchstabe, oder alles Großbuchstaben, hat keine Klammern
• Ach, was schweif ich denn in der Welt rum, bleiben wir bei wikimedia.org und schaun uns mal eine der üblichen OOP-Dokus an; und die saubere Aufteilung in Eigenschaften ohne Klammern, später Methoden mit Klammern, und die Konstruktoren und deren Steuerung gesondert vor Eigenschaften und Methoden.
• Du saugst dir jetzt grad ein privates Weltbild aus den Fingern, das niemand kennt, niemand verwendet, um nachträglich deinen undurchdachten Blitz-Edit zu bemänteln.
• Die oben mehrfach von mir aufgezählte Abfolge (mindestens: Erst Konstruktoren, danach Methoden; auf gar keinen Fall niemals nirgends beides unter derselben Überschrift „Methoden“ wie du es bei deinem Spontan-Umschmeiß-Edit verbrochen hattest) ist seit Jahrzehnten Standard in allen OOP-Sprachen. Wenn du angeblich was davon verstehen würdest, könntest du keine solchen „didaktischen“ Vorschläge aushecken.
• Die Hilfeseiten folgen einheitlich der OOP-Logik und bleiben alle so wie sie sind. Habe ich mich da klar und deutlich ausgedrückt?
  • Dein vorgestelltes „Konzept“ scheitert schon schlicht daran, dass es im hiervon dokumentierten Scribunto keine einzige Konstruktor-Funktion (bei keiner Bibliothek) gibt, sondern nichts anders als statische Bibliotheksfunktionen, eine wie die andere.
  • Du müsstest dich mal für eine Rolle entscheiden. In der LWS und die Jahre hindurch bejammerst du regelmäßig, das wäre für dich alles zu schwer verständlich und du bräuchtest für jede einzelne der 80 aufgelisteten Funktionen nochmal ein einzelnes Anwendungsbeispiel mit fertigem Programmcode; die vier exemplarischen Fälle, die analog auf alle anderen 76 anzuwenden sind, würden für dich nicht ausreichen. Danach gibst du hier den großen Didaktiker, der die Scribunto-Bibliotheken in- und auswendig keent und genau weiß, wie alles dokumentiert werden müsse. Zwischen diesen beiden Rollen kannst du nicht alle zehn Stunden wechseln. Ich verbleibe dann mal bei der ersten Darbietung; du möchtest gern aufs Töpfchen gesetzt werden und dein unsinniger umseitiger Edit war nur Show mit nichts dahinter – ohne selbst verstanden zu haben worum es inhaltlich geht. Tiefes Verständnis der Materie einschließlich aller Hintergründe ist jedoch Voraussetzung, um an einer Hilfeseite mehr als nur einen offenkundig vergessenen Buchstaben ausbessern zu dürfen. Gemäß deiner regelmäßigen Rückfragen in der LWS mangelt es dir jedoch an genau dieser Kompetenz. Also kannst du nicht einfach unangekündigt über eine Hilfeseite herfallen und sie verwüsten. Zukünftige unabgesprochene Edits von dir an Lua-Hilfe- und Projektseiten über triviale Schreibfehlerberichtigungen hinaus werde ich diskussionslos revertieren.
• Zur Vokabel „wirkungsgleich“ fehlen mir schlicht die Worte.
  • Wenn du den dort angegebenen Lua-Code für das momentane Objekt ausführen würdest, bekommst du exakt das gleiche Resultat als wenn du diese Eigenschaft abfragen würdest.
  • Das ist meist eine Trivialität, kann aber in spitzfindigen Fällen etwas diffizil werden.
  • Bei den anderen Eigenschaften dieses title-Objekts ist jeweils näher beschrieben, was wäre wenn.
  • Entscheidend ist die Aussage, dass dies ein neues title-Objekt liefern würde, weil mw.title.makeTitle() auch ein neues Objekt generiert, und alle Hinweise zu teuren Funktionen gelten für dieses analog.
  • Diese Eigenschaft ist gewissermaßen eine Konstruktorfunktion.
  • Sie erbt alle Nebenbedingungen von den anderen Beschreibungen, auf die dabei jeweils verwiesen wird.
  • Es ist letztlich nur eine abkürzende Schreibweise für den von mir explizit angegeben Code.
  • Auch wenn du es nicht in den Schädel kriegst: Wenn auf diese Eigenschaft zugegriffen wird, dann wird intern eine Funktion ausgeführt, die diese Wirkung hat, und erspart dem Anwender, das selbst machen zu müssen. Spätestens mit dem ersten Zugriff. Weil du bei einem title-Objekt nachträglich nichts mehr an der zugeordneten Seite ändern kannst, mag man das auch cachen.
  • Du findest die Programmierung unter mw.title.lua ab Zeile 226.
  • In mw:Extension:Scribunto/Lua reference manual #Title library nennen die das übrigens The same as – ‚das gleiche wie‘. Ich fände ja The same effect as noch präziser.
  • Was genau kann jemand an der Vokabel „wirkungsgleich“ angeblich nicht verstanden haben wollen? Es hat die gleiche Wirkung, einschließlich sämtlicher Nebenwirkungen.
• Du kostest mal wieder mehr als eine Stunde Zeit; das werde ich deinem tiefroten Benutzerkonto für dieses Jahr zu Lasten buchen. Für Juni/Juli 2020 ist dein Aufwandskonto nicht mehr belastbar.

--PerfektesChaos 15:18, 30. Jun. 2020 (CEST)

Es ist eigentlich völlig egal, ob diese OOP "echt" oder quasi "emuliert" wird, solange die Anwendung analog ist. Was es deine Kritik an meinem häufigen "Umschwenken" angeht: Ich versuche ganz einfach, das hier etablierte Lua-System - so will ich es mal nennen - mit den mir bekannten Sprachen wie C++ zu vergleichen und diese Bibliothek komplett zu verstehen. Dazu braucht man die Info über alle Funktionen, auch die weniger bekannten. Wie auch immer: Ich werde wohl schlichtweg mehr mit Hilfe eines allgemein nicht benutzten Test-Moduls herumprobieren. Was fehlt, ist eine Möglichkeit zum Debugging. Wenn du möchtest, dass ich hier nicht mehr soviel nachfrage, dann wäre es nett, wenn du mir trotz "überzogenem Konto" noch verraten würdest, wie ich eine Instanz dieses Lua-System hier auf meine Festplatte bekomme. Dann kann ich mehr offline testen. ÅñŧóñŜûŝî (Ð) 19:44, 30. Jun. 2020 (CEST)