Hilfe Diskussion:Lua/Modul im Wiki

Zusammenlegen

Die Seite sollte mit Hilfe:Lua zusammengelegt werden. Der Inhalt ist teilweise doppelt und die Grenzziehung ist unnötig. ÅñŧóñŜûŝî (Ð) 14:35, 14. Mai 2013 (CEST)

Funktionen für Vorlagen und zusätzlich Lua-Zugriff

Die Dokumentation scheint mir an dieser Stelle schlecht zu sein. Ich kann aber nicht ausschließen, dass ich selbst da etwas falsch verstanden habe. Jedenfalls fehlt die entscheidende Form der Einbindung in ein aufrufendes Modul.

Durch eigene Programmierung zunächst auf Grundlage dieser Dokumentation bin ich zu folgendem Schluss gekommen:

Das Beispielmodul exportiert das Objekt DiesesBeispiel auf eine Weise, die erheblich umständlicher ist, als notwendig.

Sei eine Einbindung

local _, Dings = pcall(require, "Modul:DiesesBeispiel")
local result1 = Dings.service(<Param>)
local Bums = Dings.DiesesBeispiel()
local result2 = Bums.service(<Param>)

dann liefert result1 das Ergebnis von p.service, während result2 das Ergebnis von DiesesBeispiel.service liefert. Dies wäre jedenfalls der Fall, wenn das Beispielmodul an Stelle der function p.DiesesBeispiel() die Zeile

p.mod.service = DiesesBeispiel.service

enthielte und result2 mit Dings.mod.service(<Param>) belegt würde.

Was also ist die schlaue Form der Einbindung, die den Export des DiesesBeispiel - Objektes durch eine parameterlose DiesesBeispiel()-Funktion voraussetzt? --Vollbracht (Diskussion) 00:10, 9. Jan. 2022 (CET)

Als neuen Inhalt dieses Abschnittes schlage ich wie nachfolgend vor:

neuer Inhalt

Auch wenn mit local _, Mod = pcall(require, <ModulName>) auf Inhalte eines Moduls zugegriffen wird, auf die mit {{#invoke:<ModulName>|<FunktionsName>[|<Parameter>]*}} aus Vorlagen heraus ebenfalls Zugriffe erfolgen können, kann nur auf das eine Objekt zugegriffen werden, welches am Ende auch vom Modul zurück gegeben wird. Gegeben sei das folgende Beispiel eines Modul:MeinModul

--[=[ MeinModul <Jahr>-<Monat>-<Tag>
Example Module for Access from Within Templates and Other Modules
Author: <initial author>
* MeinModul.MeineFunktion1(Param)
* MeinModul.MeineFunktion2(Param)
]=]

--Module globals
local p = {service = {}}

p.service.MeineFunktion1 = function(Param)
    -- Was auch immer mit Param gemacht werden soll...
    return <irgendwas>
end

p.service.MeineFunktion2 = function(Param)
    -- Was auch immer mit Param nur für andere Moduln gemacht werden soll...
    return <irgendwas>
end

p.MeineFunktion1 = function(frame)
    -- frame.args auf fehlende / fehlerhafte Parameter prüfen
    -- Param erstellen
    -- Servicefunktion aufrufen
    return p.service.MeineFunktion1(Param)
end

p.MeineFunktion3 = function(frame)
    -- frame.args auf fehlende / fehlerhafte Parameter prüfen
    -- Was auch immer nur für Vorlagen gemacht werden soll...
    return <irgendwas>
end

return p

Als Konvention sei an dieser Stelle der Bezeichner „service“ für alle neuen Moduln als Standardbezeichner für alle Objekte eingeführt, auf die aus einem anderen Modul heraus zugegriffen werden soll, während alle Funktionen, die nicht in diesem Objekt sind, in diesem anderen Modul unbekannt sein sollen. Alle Moduln, die dieser Konvention folgen, können nun wie folgt eingebunden werden:

local p = {}

local function getService(ModName)
	local _, Mod = pcall(require, ModName)
	assert(type(Mod) == 'table',
	       '404 Module fehlen / missing ' .. ModName)
	assert(type(Mod.service) == 'table',
		   'Object fehlt / missing: ' .. ModName .. '.service')
	return Mod.service
end

local MeinModul = getService("Modul:MeinModul")
local MeinModul2 = getService("Modul:MeinModul2")
local MeinModul3 = getService("Modul:MeinModul3")

p.neueFunktion = function(frame)
    local Wert1 = MeinModul.MeineFunktion1(Param)
    local Wert2 = MeinModul.MeineFunktion2(Param)
    -- MeinModul.MeineFunktion3(Param) ist hier unbekannt
end

return p

In Vorlagen können Funktionen hingegen mit

 {{#invoke:MeinModul|MeineFunktion1}}
 <!-- MeineFunktion2 ist hier unbekannt. -->
 {{#invoke:MeinModul|MeineFunktion3|MeinParameter}}

eingebunden werden.

Diskussion dieses Vorschlags

Ich bitte hierzu um Beiträge. --Vollbracht (Diskussion) 02:23, 9. Jan. 2022 (CET)

Der Vorschlag bezieht sich auf wenige wesentliche Änderungen in der Implementierung neuer Moduln:

1. Der Modulname taucht nicht mehr als Objektname im Modul auf. Das hat nach außen zunächst keinerlei Auswirkungen, vermeidet jedoch Missverständnisse bei denen, die hier neu anfangen. Um Diskussion dieser Änderung bitte ich unten unter # Modulname als Objektname im Modul.
2. Das Objekt, welches im aufrufenden Modul seine Methoden bereitstellen soll, wird nicht mehr über eine Funktion, sondern als Tabelleneintrag direkt bereitgestellt. Die Funktion tat nichts anderes, war also nur ein unnötiger Zwischenschritt.
3. Das Objekt, welches im aufrufenden Modul seine Methoden bereitstellen soll, sollte stets den selben Namen haben, um in aufrufenden Moduln den Programmieraufwand zu verringern und die Wiederverwendbarkeit von Code zu erhöhen. --Vollbracht (Diskussion) 03:15, 11. Jan. 2022 (CET)

Diskussion zur Qualifikation von Beteiligten

„Ich kann aber nicht ausschließen, dass ich selbst da etwas falsch verstanden habe.“

• Davon gehe ich sehr stark aus.
• Insbesondere habe ich den Eindruck, dass du eine Brille aus einer anderen Welt aufgesetzt hast, durch die sich bestimmte unvermeidliche Eigenarten der Welt Lua@Wiki nur verzerrt wahrnehmen lassen.
• Am besten, du liest und verwertest genau das, was dort wörtlich steht, und nichts anderes.
• Im Übrigen steckt hier objektorientierte Programmierung (OOP) dahinter.
  • Die muss niemand kennen, um Lua-Funktionen benutzen zu können.
  • Das Verständnis ist jedoch wesentlich, um das Konzept dahinter zu begreifen.

„Jedenfalls fehlt die entscheidende Form der Einbindung in ein aufrufendes Modul.“

• ????? Hilfe:Lua/Modul im Wiki #Rückgabewert.
• Alles, was darüber hinausgeht, liegt in der Verantwortung derjenigen, die ein Modul anbieten, und liegt nicht im Dokumentationsbereich dieser Hilfeseite.
• Verlinkt wird a.a.O. auf Hilfe:Lua/Modul im Wiki #require().
• Umseitig stehen jeweils beide Seiten im Detail, anbietende und nutzende, und das sowohl in der Lua- wie in der Wikitext-Welt, und jeweils mit Beispielen. Da fehlt nix.

Zwei Vorbemerkungen ansonsten:

1. _ Sowas verwenden wir nicht, weder als Name einer Variablen noch als Präfix.
   • Es ist unverständlich, die Bedeutung erklärt sich nicht, irgendwelche darin verborgenen Geheimnisse sind unergründlich.
   • Wenn es in einer Überschrift der Dokumentation genannt wird, dann erscheint es in Fragmentbezeichnern als Leerzeichen. Macht nur Ärger.
2. „Als Konvention sei“ .service
   • Wenn das jetzt so zu verstehen sein soll, dass wir hier deinen Code als neue Konvention einführen sollen – nein, ganz ganz ganz sicher nicht.

Zusätzliches Beispiel:

• Umseitig steht bereits alles, und zwar vollständig und so laienhaft verständlich wie irgend möglich.
• Du kannst aber mal Modul:URLutil als produktives Beispiel durcharbeiten. Vielleicht etwas einleuchtender als ein auf wenige Zeilen ohne echten Nutzen konstruiertes fiktives Hilfeseiten-Beispiel, das sehr kurz und übersichtlich sein muss.
  • Schau dir die Doku für Vorlagenprogrammierer an.
  • Schau dir dann den Abschnitt für Lua-Programmierer an.
  • Da steht alles bei.
  • Vergleiche dies mit dem Lua-Code.
• Modul:DateTime ist unser einziges und tatsächlich wie ein Objekt aus der OOP handhabbares Modul. Solche Objekte lassen sich miteinander vergleichen, es kann ein Monat dazugezählt oder abgezogen werden, es kann konstruiert oder sein interner Wert als Zeichenkette dargestellt werden, oder es kann in unterschiedlichen Formatierungen präsentiert werden.

Zwei Welten: Wikitext und Lua

• Bei Lua@Wiki gibt es zwei Funktions-Schnittstellen, eine für Vorlagenprogrammierung in Wikitext und ggf. eine, wenn ein Modul eine für ein anderes Lua-Modul sinnvolle Funktionalität anbieten kann.
• Die Lua-Funktion kann mit unterschiedlichen Datentypen aufgerufen werden: Zeichenkette, Boolean, numerisch, und vor allem das komplexe table. Sie kann auch einen oder mehrere beliebige Datentypen zurückgeben.
• Die Wikitext-Schnittstelle #invoke: bildet die Parameter von Vorlagen nach oder kann Vorlageneinbindungen direkt auslesen.
  • Die Wikitext-Schnittstelle kennt aber nur einen einzigen Datentyp: Zeichenkette.
  • Die wesentkliche Aufgabe der Wikitext-Schnittstelle ist es deshalb, die Zeichenketten-Parameter zu parsen, also ggf. in andere Datentypen zu wandeln, und zum Schluss das Ergebnis in eine einzige sinnvolle Zeichenkette zu wandeln. Ggf. gibt es auch Fehler wegen ungültiger Zeichen in der Zeichenkette, also etwa bei der Generierung eines numerischen Wertes, was beim numerischen Datentyp selbst nie vorkomen kann.
  • Mit den konvertierten Eingabewerten kann die Lua-Funktion für die inhaltliche Arbeit aufgerufen werden, und anschließend das Lua-Ergebnis in eine Wiki-geeignete Zeichenkette transformiert werden.
• Beispiele:
  • Wir wollen bei der Vorlagennutzung einen leeren Parameterwert, oder nur aus Whitespace bestehend, genauso behandelt wissen als ob kein Wert angegeben wurde. Leerzeichen um unbenannte Parameterwerte sollen grundsätzlich ignoriert werden.
    • Also muss eine Zeichenkette erstmal getrimmt werden.
    • Eine leere Zeichenkette ist im Sinne der Lua-Welt aber „etwas“ und nicht „nichts“ . Also muss im Fall von "" der Wert in false gewandelt werden.
  • Als Ergebnis einer Vorlage soll kein false oder true herauskommen, sondern die Parserfunktionen #if: usw. benötigen
    • leere Zeichenkette = nein
    • nichtleere Zeichenkette = ja
    • Wir verwenden dabei 1 als globalen in allen menschlichen Sprachen verständlichen Wert für „ja“.
    • Umgekehrt sollen die Eingabeparameter 0, -, no, nein, false in Lua als false verstanden werden. Sind aber Zeichenketten mit was drin und nicht nichts. Muss man was für tun.

Kleine Vertiefung: objektorientierte Programmierung

• Das (fortgeschrittene) Modul lässt sich als ein Objekt betrachten; unabhängig davon ob die Sprache Lua selbst objektorientiert wäre. Zumindest können alle Konzepte übernommen werden.
• Ein solches Objekt hat:
  • Eine Konstruktorfunktion,
  • einen Objekt-Typ,
  • öffentliche Methoden,
  • Operatoren,
  • ggf. öffentliche Eigenschaften (mit Vorsicht zu genießen; öffentlicher Direktzugriff ist gefährlich und verleitet zu schlechten Praktiken – ggf. können aber Konstanten relativ bedenkenlos nach draußen mitgeteilt werden).
• Ein Objekt heißt bei uns genauso wie das Modul.
  • Die Konstruktorfunktion heißt genauso wie das Objekt, was universelle Konvention in der objektorientierten Programmierung ist.
• Ein rohes Objekt erhält man, indem über die Schnittstelle Lua@Wiki diejenige Funktion aufgerufen wird, die genauso heißt wie das Objekt.
  • Anschließend muss dem Objekt aber Gelegenheit gegeben werden, sich bei Bedarf zu initialisieren; das ist die Konstruktorfunktion.
  • Die Konstruktorfunktion im rohen Objekt heißt genauso wie das Modul.
  • URLutil erklärt genau diesen Vorgang.
  • Das initialisierte Lua-Objekt stellt anschließend öffentliche Methoden bereit.

VG --PerfektesChaos 13:03, 9. Jan. 2022 (CET)

Hallo Chaos! Danke für Deinen umfangreichen Beitrag, der leider wieder nicht ohne unnötige Spitzen ausgekommen ist. (WP:KPA) Vieles sollte in der Dokumentation für die Lua-Programmierung in WP stehen, gehört aber hier nicht zum Thema. Deshalb hier nur zum Wesentlichen:

• Alles, was Du hier und in Deiner Moduldokumentation geschrieben hast bestätigt, dass ich in allen meinen bisherigen Aussagen in diesem Abschnitt richtig gelegen habe, nur nicht mit der Möglichkeit, etwas falsch verstanden zu haben.
• Der von Dir verlinkte Abschnitt für Lua-Programmierer in der Dokumentation zu URLutil war die entscheidende schlaue Form der Einbindung in ein aufrufendes Modul. Was habe ich danach gesucht!
• "_" als üblicher Name einer Variablen, die sofort verworfen, also nie ausgelesen wird, war nicht meine Idee.
• Die Fehlerbehandlung für fehlende Moduln sollte mit assert ausgeführt werden, um mit Abschluss der Compile-Zeit keine unnötigen Abfragen zurück zu lassen. Das gilt für alle Moduln, deren Verwendung mehr ist, als nur eine nette Zusatzoption.

Es stehen jetzt zwei Varianten für eine standardisierte Zugriffsgestaltung zur Auswahl:

local service = {}
local p = {}
service.mach = function(par)
  ...
end
p.mach(frame)
  ... -- (parse)
  service.mach(...)
end
-- Variante 1:
p.service = service
-- Variante 2:
p.service = function()
  return service
end
return p

Beide Varianten kapseln nur fakultativ. Aufrufende Moduln haben die Freiheit, einen Zugriff zu implementieren, der alle Methoden von p bereitstellt, oder einen, der nur jene bereitstellt, die Methoden von service sind. Ich schlage daher vor, die einfachere der beiden, wie im Vorschlag für den neuen Inhalt angegeben, in die Hilfeseite zu übernehmen. --Vollbracht (Diskussion) 14:18, 9. Jan. 2022 (CET)

„Der von Dir verlinkte Abschnitt für Lua-Programmierer in der Dokumentation zu URLutil war die entscheidende schlaue Form der Einbindung in ein aufrufendes Modul. Was habe ich danach gesucht!“

• Das steht umseitig und buchstabengetreu unter Hilfe:Lua/Modul im Wiki #Einbindung. Genauer gesagt: Eine exakte Kopie, bis auf den Modulnamen, wie sie in allen einschlägigen Bibliotheksmodulen textgleich zu finden ist.
• Was genau war jetzt an den Überschriften „Mehrere Module – Einbindung“ so schwer zu verstehen? Du hast Modul A und möchtest Modul B einbinden. Genau das war deine Frage gewesen. Genau dies beantwortet das umseitige Inhaltsverzeichnis. Mehr kann die Hilfeseite nicht leisten. „fehlt die entscheidende Form der Einbindung in ein aufrufendes Modul“ [Hervorhebung von mir].
• Deine Wertungen mit „schlecht“ und „fehlt was“ sind schlicht inadäquat.
• „Lua-Modul im Wiki“ sind eine hochkomplexe Angelegenheit und nicht mal eben auf einen Zwei-Minuten-Blick auf die Hilfeseite zu erfassen.
• Die Erfahrung lehrt, dass es in der Regel zwölf Monate kontinuierlicher Befassung mit Lua@Wiki bedarf, bis das wirklich richtig verstanden wurde, und in allen Konsequenzen und negativen Folgen bei Missachtung der Empfehlungen erlernt wurde. Ich selbst war erst nach anderthalb Jahren soweit, robuste produktive Module schreiben zu können.

_ war nicht meine Idee

• Dann vergiss sie ganz schnell wieder.
• Extrem schlechter Stil.
• Nimm i j k für Zahlen, s für Zeichenketten, v für unbekannten Typ, oder inhaltlich selbsterklärende Kürzel.

„Die Fehlerbehandlung für fehlende Moduln sollte mit assert ausgeführt werden“

• Du hast die Konsequenzen im Wiki und für die anderen Beteiligten nicht begriffen.
• In den nächsten zwölf Monaten solltest du besser auf Ratschläge verzichten und keine Nicht-Wiki-Welt-Ideen vortragen.

„erheblich umständlicher ist, als notwendig“

• Du hast die Konsequenzen im Wiki und für die anderen Beteiligten nicht begriffen.
• In den nächsten zwölf Monaten solltest du besser auf Ratschläge verzichten und keine Nicht-Wiki-Welt-Ideen vortragen.

Dein Code-Beispiel service ist, wie ich mit OOP dargelegt habe, keine Verbesserung. Objekte tragen den Bezeichner des Objekts und nicht irgendwelche privat ausgedachten Bezeichner, die außer dir niemand versteht.

„leider wieder nicht ohne unnötige Spitzen“

• Dir sollten ja eigentlich Balken im eigenen Auge gut vertraut sein.
• Wer seine Anfrage mit „Stelle schlecht zu sein“ und „Jedenfalls fehlt die entscheidende Form“ eröffnet, aber die Hintergründe überhaupt nicht kennt, und noch nicht einmal im Inhaltsverzeichnis die Abfolge „Mehrere Module – Einbindung“ findet, sollte sich jeglicher Vorschläge enthalten, wie man das ja alles ganz anders machen könnte, wenn man gar nicht überblickt, welche Nachteile das hat.

VG --PerfektesChaos 15:08, 9. Jan. 2022 (CET)

• "Bis auf den Modulnamen..." Genau! Denn der Zusammenhang hat sich aus dieser Doku nicht im Geringsten erschlossen. Das war schlecht. Da fehlte was.
• Balken im Auge: Kannst Du mir vorwerfen, wenn es konkret wird. Hier hatte ich nur gegen schlechte Inhalte gewettert. Das hatte ich auch begründet. Deine persönlichen Fähigkeiten werde ich nicht kommentieren. Das werde ich bei niemandem tun.
• Objektorientierte Programmierung kann ich schon eine ganze Weile. Wie ich jetzt weiß, geschieht die konzeptionell in Lua ganz analog zu Javascript. Erwarte nicht, dass ich noch einen Tag brauche, bis ich die verstanden habe. Lua ist nicht meine erste Programmiersprache. Ich beherrsche bereits einige. Nur keine war schlechter dokumentiert.
• Lua@Wiki ist keine Hexerei. Das allermeiste ist viel einfacher, als am Anfang gedacht. Wenn ich hier noch Fragen stelle, dann kann die jemand, der sich damit auskennt, beantworten. Ich weiß nicht, warum Du das nicht tust. Maulkorb und Hinweis auf zu wenig Erfahrung sind jedenfalls der falsche Ansatz. Wenn Du meine Beiträge genauer verfolgst, solltest Du gemerkt haben, dass ich nicht auf Programmierer-, sondern auf Softwareentwicklerniveau arbeite. Ich kann also nicht nur robust schreiben, wo das Not tut, sondern auch Projekte starten und zu Ende bringen.

Und jetzt bitte zurück zum Thema: Variante 1, oder Variante 2? Nachteile von Variante 1 kann ich noch nicht sehen. Wenn Du welche siehst, dann nenn sie und rede nicht um den heißen Brei. Wenn Du keine siehst, dann werte ich das als Unterstützung für meinen Vorschlag. --Vollbracht (Diskussion) 20:34, 9. Jan. 2022 (CET)

Du lässt ganz schlicht und einfach die Finger von der umseitigen Hilfeseite.

• Dein komisches service ist eine von ganz vielen gleichberechtigen Anwenderfunktionen oder Feldnamen; wie sie etwa in URLutil dutzendweise aufgelistet sind, und geht mittendrin unter.
• Wenn du tatsächlich etwas von OOP verstehen würdest, dann wüsstest du zwei Dinge:
  1. Der Name des Objekts ist der Name des Objekts ist der Name der Konstruktorfunktion.
     • Er ist deshalb einzigartig und aus der Masse normaler Methoden herausgehoben.
  2. Man gibt nie nie niemals den direkten öffentlichen Zugriff auf das innere Objekt frei, sondern man macht das immer nur über einen Funktionsaufruf zugänglich, wodurch man immer die Möglichkeit hat, bei späterem Bedarf auch eine Initialisierung auszuführen, selbst wenn das momentan noch nicht erforderlich ist. Andernfalls müsste man nachträglich eine global unübersehbare Zahl von Anwendungen umbauen, die einem aber gar nicht gehören.
• Die deWP ist das einzige Wiki, das sich den Luxus leistet, in eigener Sprache vollständige eigene Hilfeseiten zu Lua@Wiki bereitzuhalten. Wenn dir umseitig nicht gefällt, kannst du auf mw: die offizielle Doku lesen; wenn sie dir besser gefällt, dann prima und du brauchst hier nichts mehr nachzulesen und nichts mehr zu fragen.
• Und um es nochmals überdeutlich unmissverständlich klar zu machen: Ich als Ersteller und wesentlicher Hauptautor des fraglichen Bereichs bin nicht mit deinem Begehren einverstanden, und es ist eine Rotzfrechheit, hier per „dann werte ich das als Unterstützung für meinen Vorschlag“ irgendwelche Ultimaten zu setzen und vorgebliche Unterstützung für irgendwelchen Quatsch aus irgendwas abzuleiten.

--PerfektesChaos 22:16, 9. Jan. 2022 (CET)

Es gibt tatsächlich konzeptionell sehr unterschiedliche Sprachen. Was Du schreibst, passt genau zu Sprachen, wie C++, C#, Delphi, oder Java. Dass Du das hier schreibst, zeigt, dass Du den Unterschied zwischen diesen Sprachen auf der einen Seite und Javascript und Lua auf der anderen Seite nicht erkannt hast. Du wirfst hier mit Fachbegriffen um Dich, die ich als ausgebildeter ehemaliger Profi in diesem Bereich sehr wohl kenne. In diesem Zusammenhang passen sie jedoch nicht. Also steig endlich von Deinem hohen Ross 'runter. Lua kennt keine Klassen und folglich auch keine "Konstruktorfunktion". Es kopiert Objekte. Und ich hatte Dich bereits oben darauf hingewiesen, dass Deine Kapselung von wegen "Zugriff auf das innere Objekt" fakultativ ist. Sie unterscheidet sich somit nicht im Geringsten von der meinen. Also werd konkret! Was ist der Vorteil von Variante 2? Was versuchst Du damit zu erreichen? --Vollbracht (Diskussion) 22:38, 9. Jan. 2022 (CET)

Namenskonventionen

Wer Modul-, Objekt- und Instanznamen durcheinander wirft, bekommt Probleme. Gerade in der Dokumentation darf so etwas nicht passieren. Meine anfänglichen Schwierigkeiten mit Lua im Wiki waren genau darauf zurückzuführen, dass die Dokumentation hier ungenügend war.

Es hat sich gezeigt, dass zu viele Konventionen leicht zu Verwerfungen zwischen Entwicklern führen. Daher schlage ich vor, mit Namenskonventionen sparsam zu sein. Sollte sich jedoch in einem, oder mehreren der folgenden Abschnitte herauskristallisieren, dass uns einige Konventionen wichtig sind, dann sollten die entsprechenden Ergebnisse auch mit Geltungsbereich in Lua/Modul im Wiki veröffentlicht werden. --Vollbracht (Diskussion) 22:47, 9. Jan. 2022 (CET)

Modulname als Objektname im Modul

Grundsätzlich ist es möglich, für ein prominentes Objekt im Modul auch den Modulnamen zu verwenden. Auf die Verwendung des Moduls hat das nach außen keinen Einfluss. Es ist bislang hier gängige Praxis, führt jedoch bei denen, die sich diese Sprache neu aneignen, zu Verwirrung. Es suggeriert eine Verbindung mit dem Zugriff von außen, die nicht existiert. Ich empfehle daher, bei künftigen Moduln nach Möglichkeit hierfür andere Bezeichner zu verwenden. --Vollbracht (Diskussion) 22:47, 9. Jan. 2022 (CET)

Modulname als Methodenname im Modul

Hier gilt ähnliches, wie bei Objektnamen. Darüber hinaus erschwert es eine Standardisierung der Einbindung in andere Moduln, wenn die Standardmethode zur Eingrenzung des Zugriffs in jedem Modul anders (nämlich wie das Modul) heißt. An dieser Stelle macht eine Namenskonvention Sinn: Ich schlage vor, hier einen stets gleichen Bezeichner zu wählen. Ob dieser Zugriff jedoch über eine Standardmethode, oder, wie oben vorgeschlagen, über einen Direktzugriff auf das prominente Objekt erfolgt, wird oben diskutiert. --Vollbracht (Diskussion) 22:47, 9. Jan. 2022 (CET)

Modulname als Instanzname im aufrufenden Modul

Mit einiger Phantasie kann ich mir vorstellen, dass künftige Anwender in ihrem neuen Modul mehrere Instanzen meines Moduls, oder unterschiedliche bereitgestellte Objekte aus einem einzelnen importierten Modul benötigen. Dann und nur dann halte ich es für falsch, den Modulnamen auch für die verwendeten Instanzen zu nutzen. Eine Konvention in dieser Hinsicht halte ich jedoch nicht für notwendig. --Vollbracht (Diskussion) 22:47, 9. Jan. 2022 (CET)

Einzelne Buchstaben als Bezeichner

Es ist natürlich verbreitet und bequem für Indizes in Schleifen Buchstaben, wie i, j, oder k zu verwenden. Sollte der Schleifenkörper jedoch umfangreicher werden, sollte auch für den Index ein sprechenderer Name gewählt werden. Ähnliches gilt dann natürlich auch für Name-Value-Paare in for-Schleifen, die gerne mit n und v bezeichnet werden. Auch der Underscore ist ein solcher grundsätzlich zulässiger Bezeichner. Er wird jedoch von etlichen Lua-Programmierern grundsätzlich nur für Variablen verwandt, die nie ausgelesen werden, also nur als Platzhalter fungieren. Daher sollte er anders auch nicht verwendet werden. Es gibt auch Entwickler, die seine Verwendung grundsätzlich ablehnen und als schlechten Stil bezeichnen (warum auch immer). --Vollbracht (Diskussion) 22:47, 9. Jan. 2022 (CET)