Ein kurzer Tip am Rande mit ein wenig Bla Bla drum rum:

Was ist ein Konstruktor?
In objektorientierten Sprachen (C++, Delphi) gibt es Objekte. Diese müssen irgendwo im Speicher des Programms abgelegt werden, d.h. Speicher muss reserviert und ggf. initialisiert werden, und genau das macht der Konstruktor.

Ein Konstruktor ist eine Funktion eines Objekts, die geufen wird, wenn ein Objekt erzeugt werden soll, da das häufig etwas komplizierter ist, als nur zu sagen "diese paar Byte gehören nun zu diesem Objekt".

Warum erzähle ich das in einem Tutorialforum für den GM?
Weil der GM auch sowas wie einen Konstruktor bereit stellt: Das Create Event.
Wenn man die Funktion

ruft, wird zunächst die Instanz von obj erzeugt, dann das Create Event ausgeführt, und erst dann wird wieder zu der Funktion zurückgekehrt, die instance_create() gerufen hat.

Und wo ist nun das Problem?
Der Unterschied zwischen einem Konstruktor in objektorientierten Programmiersprachen und dem Create Event im GM ist nun, dass man den Konstruktoren auch Parameter mitgeben kann, die sie dann verwenden können. Beim Create Event ist dies nicht möglich, da muss man, wenn man variable Werte von außen mitgeben möchte, erst das Create Event ablaufen lassen, und dann über

oder

herumtricksen.

Was ist nun aber, wenn das Objekt so entworfen wurde, dass das Create Event unbedingt einen oder mehrere bestimmte Parameter braucht? Und was, wenn dieses Create Event nicht gerade kurz ist?

Jedes Mal, wenn man eine Instanz dieses Objekts erzeugen will,

zu rufen ist recht umständlich, und bläht den Code nur auf.

Besser ist es zwar schon, dies alles in ein Skript auszulagern, aber auch diese Methode hat den Nachteil, dass erst das Create Event ausgeführt wird, und dann mit Variablen jongliert wird.

Und nu?
In gewissen Programmiersprachen gibt es immer eine Funktion mit dem Namen "main", die automatisch als erste bei Programmstart gerufen wird, und die das eigentliche Programm ist. Diese Funktion hat dann üblicherweise zwei Parameter: "argc" und "argv" (argument counter und argument vector). Die erste Variable gibt an, wieviele Parameter dem Programm übergeben wurden, der zweite enthält dann die Parameter in einem Array aus Strings (oder so ähnlich). Der GM hat das mit parameter_count() und parameter_string() übrigens auch.

Auf dieses Prinzip kann man nun jedenfalls bei dem Problem mit dem Konstruktor zurückgreifen:

Man richtet sich eine globale Variable "argv" ein,

und benutzt diese als Ablage für die Parameter.

Nun kann man sich einen "Konstruktor" wie folgt schreiben:

und im Create Event dann die Parameter auslesen:


Und schon kann man über

Instanzen erzeugen und gleichzeitig Parameter übergeben.

Ich möchte nun aber in unterschiedlichen Situationen unterschiedliche Parameter übergeben.
Kein Problem. Entweder man reserviert sich auch "argc" (oder eine andere Variable) als weitere globale Variable oder nutzt "argv[0]", um eine Zahl quasi als "Konstruktor-ID" zu übergeben. D.h. für jede unterschiedliche Situation, in der man einen anderen Konstruktor braucht, schreibt man sich eine eigene Funktion "obj_foo_createN()", und jede schreibt dann eine eigene Zahl in argc oder argv[0]. Dann prüft man im Create Event diese Zahl, und je nach dem, welche da steht, wertet man die übrigen Werte von argv aus.

Oder man bleibt bei einem Konstruktor, und nutzt argument2, um die ID des Konstruktors anzugeben, den man möchte.

Ich mag aber keine globalen Variablen
Geht auch ohne, aber die Methode mag ich nicht, deswegen reiße ich sie nur mal kurz an:
Man erstellt sich ein Objekt "obj_Konstruktor" oder "obj_fooK", erzeugt davon im Konstruktor eine Instanz, schreibt die übergebenen Parameter dort rein, und erstellt dann das eigentliche Objekt. Dieses holt sich nun seine Parameter aus dem Konstruktor-Objekt, welches im Anschluss wieder gelöscht wird.

Da das nur gut geht, wenn ein Objekt in seinem Create Event keine anderen Instanzen von sich selbst erzeugen soll, und weil dabei ständig temporäre Instanzen erzeugt und wieder gelöscht werden, präferiere ich doch eher die Lösung mit der einen globalen Variable.

Wer mit dem GM programmiert, der 16 Byte für einen boolschen verbraucht, sollte bei einem Array nicht von verschwendetem Speicher sprechen.

Ein konkretes Beispiel, was ich meine, kann ich leider nicht liefern, da ich die genauen Details nicht kenne (dieses Tutorial entstand, weil sich jemand beschwerte, dass das Create Event ausgeführt wird, bevor man Variablen übergeben kann).

Aber wenn man ein Create Event hat, das unbeding einen Wert für eine gewisse Variable (z.b. foo) braucht, um zu funktionieren, dann kann man auch statt meiner Krücke schreiben:


Und wie gesagt: Dies überall hinzuschreiben, wo man das betreffende Objekt erzeugen will, bläht den Code auf. Es komplett in ein Skript auszulagern macht den Code unwartbarer, weil man dann nicht nur das Objekt selbst im Auge behalten muss, sondern auch jedes Skript, das man für so eine Kapselung geschrieben hat. Wenn nun der größte Teil des Codes in jedem Create Event gleich ist, hat der auch in jedem Skript drin zu stehen (und sei es durch auslagern in eine weitere Funktion). Dann muss man entweder bei Änderungen durch alle Skripte durchgehen oder den Überblick über weitere Skripte behalten.
Wenn der GM schon objektorientierte Ansätze besitzt, sollte man diese auch nutzen, und nicht dagegen arbeiten; Code, der nur von einem Objekt an einer Stelle ausgeführt wird, gehört in dieses Objekt an genau diese Stelle, und nicht in ein Skript.

Dagegen ist oben beschriebene Methode ein generischer Wrapper, der nur dazu dient, Parameter an das Create Event zu übergeben. Wenn man einen Parameter zur Angabe des Objektes nutzt, kann man auch mit einem einzigen Skript auskommen:

das man dann mit beliebig vielen Argumenten rufen kann


Dadurch wird nichts anderes getan, als Argumente an das Create Event weiterzureichen; das eigentliche Create Event vergleibt im Objekt.

Und wieso eine Zeile unübersichtlicher sein soll, als so ein riesiger Codeblock, musst du mir noch erklären.

Im übrigen verlierst du durch oben beschriebene Alternative die Möglichkeit, das Create Event des Parents zu erben, da dieses lange Skript erst gerufen wird, nachdem das tatsächliche Create Event vorbei ist.

Edit: @Soul Reaver:
Ich ging davon aus, dass diese globale Variable nur für diesen Zweck verwendet wird, und dass auch sonst keine Variable so heißt. In diesem Fall wäre ein global.* nur nervend, globalvar dürfte keine Fehler verursachen.

Dieses Problem löst man ganz leicht, indem man als Kommentar oben ins Skript schreibt, was jeder Parameter macht, als Kommentar direkt über den Aufruf schreibt, wozu welcher Parameter war, oder ab GM7 noch eleganter: Man schiebt die Konstruktor-Skripte in eine Extension, und hat dann den Konstruktor sowie die Bezeichnung der Parameter in der Vervollständigungsliste.