Frage zur Verwendung von Methoden (Objekt-Syntax / Dot-Notation / Pseudocode)

  • Hi zusammen 👋 ,

    die folgende Fragestellung entstand nur aus Interesse heraus, nicht wirklich auf Grund eines wirklichen Problems.

    In AutoIt nutzen wir Funktionen und "eigentlich" keine Objekt-Orientierung (OOP). Mir ist bewusst, das es bereits Ansätze zu OOP gibt und ich da auch mal genauer nachschauen könnte und werde, doch mal sehen was ihr so dazu meint. Was ich gern wissen möchte ist, ob man Funktionen als Methoden zu einem Objekt (im Beispielcode ist es eine Map) verwenden kann und falls ja, wie?

    ⚠ Folgend also der Pseudocode:

    • Die ersten vier ConsoleWrite, Zeile 18 - 21, sind natürlich okay soweit.
    • Danach habe ich versucht zu verdeutlichen was ich meine.
      • Ich bin hier übrigens nicht an Maps oder so gebunden (kann auch ein Objekt sein).
    • Die Funktionen (welche die Methoden des jeweiligen Objekts sein könnten) GetArea2 und GetPerim2 sollen aufzeigen wie ich mir dies vorstelle.
      • Kann auch totaler Quatsch sein, da AutoIt dafür nicht strukturiert wurde, doch mit der Einführung von Maps damals, kam mir der Gedanke ob man da "nun" irgendwas in der Richtung machen kann oder nicht.

    💡 Am Ende reine Spielerei, doch vielleicht mag jemand von euch seine 2 Cents (oder mehr) dazu hinterlassen 🤝 .

    Viele Grüße
    Sven

  • Ergebnis:

    Code
    ---------------START---------------
    Test 1
    Test 2
    "...\tmp.au3" (10) : ==> The requested action with this object has failed.:
    $mData.test()
    $mData^ ERROR

    Es geht also schon, Funktionen in Maps zu speichern... Man muss nur den ersten Parameter selbst mitgeben.
    Außerdem besteht leider das gleiche Problem, wie beim ersten Zuweisen des Wertes...
    Man muss mit den eckigen Klammern und dem String arbeiten, statt die Schreibweise mit dem Punkt zu verwenden, was das ganze etwas doof macht :/
    Naja, dafür kann man die Funktion später noch beliebig austauschen ^^

    Ansonsten kann man auch mit DllStructs arbeiten, dass hab ich aber auch nur einmal gemacht, weil das erstellen und zugreifen etwas nervig ist...

  • Danke euch beiden schon mal 🤝 . Dies ist im Prinzip "nur" wie mit Maps umgegangen werden kann, jedoch nicht ganz die Idee/der Ansatz den ich mir vorgestellt hatte.

    An sich mag ich persönlich diese Schreibweise mit Klammern und String als Key nicht wirklich. Die Dot-Notation ist so viel besser lesbar und man kennt diese ja aus vielen anderen Sprachen auch.

    Vielleicht gibt es noch andere Ansätze, doch ich schaue mir mal AutoItObject.au3 und Co. (engl. Forum) mal an.

    Danke und bis später 👌 .

    Viele Grüße
    Sven

  • Was du dir genau vorstellst ist ein Syntax-Feature.
    Wir hingegen geben nur die technische Implementierung hierfür vor.
    Im Übrigen entspricht dies dem was bei OO-Methoden allgemein im Hintergrund passiert.
    Das sind im Grunde nur ganz normale Funktionen, welche zusätzlich einen Pointer auf das Objekt erhalten.
    Manche Programmiersprachen verstecken diesen Pointer (C++, Java...), andere (Python) erfordern diesen zumindest in der Methodendeklaration - jedoch nicht mehr im Aufruf.

    Nun zurück zur Syntax: Deine Vorstellung kann mit bestehender AutoIt-Syntax nicht umgesetzt werden.
    Was hingegen möglich wäre, wäre einen Präprozessor zu schreiben.
    Dieser muss im Grunde nur vor dem AutoIt-Interpreter diese Konstrukte: $name.methode(...) zu folgendem umformen: ($name.methode)($name [,...]).

    Das sollte fix umsetzbar sein. Hier mal als schneller Einzeiler (Spezialfälle wie Zeilenumbrüche per "_" und verschachtelte Klammern mal außen vorgelassen):

    Code
    $sAutoItCode = "$mRectangle.GetPerim2($test)"
    $sAutoItCode = Execute(StringRegExpReplace($sAutoItCode, '(\$\w+)\.(\w+)\((.*)\)', '"($1.$2)($1" & ("$3"=="" ? "" : ", $3") & ")"' ))
    ConsoleWrite($sAutoItCode & @CRLF)

    Hier müsste es jedoch noch ein Gegencheck geben, welcher prüft ob die Methode als ebenjene definiert wurde (z.b. schauen ob im Quelltext Func methodenname(ByRef $self auftaucht.
    Denn sonst würde man sich eventuell vorhandene Methodenaufrufe von COM-Objekten zerschießen damit.

  • Was du dir genau vorstellst ist ein Syntax-Feature.
    Wir hingegen geben nur die technische Implementierung hierfür vor.

    Ja richtig, ist mir beides bewusst.
    Ich frage mich ob es genau für dieses Syntax-Feature eine "tolle" (klar, sehr subjektiv) Alternative gibt.

    as sind im Grunde nur ganz normale Funktionen, welche zusätzlich einen Pointer auf das Objekt erhalten.
    Manche Programmiersprachen verstecken diesen Pointer (C++, Java...), andere (Python) erfordern diesen zumindest in der Methodendeklaration - jedoch nicht mehr im Aufruf.

    Kenne ich genau so aus C# und Go (golang).

    Was hingegen möglich wäre, wäre einen Präprozessor zu schreiben.

    Daran habe ich noch gar nicht gedacht, vielen Dank für diesen Impuls 👍 . Schaue ich mir mal an.

    [...] jedoch noch ein Gegencheck geben [...]

    Guter Hinweis, merci.

    Viele Grüße
    Sven