Umfrage - (Pseudo-)Datentypen in AutoIt

  • Findest Du das beschriebene Prinzip nützlich, bzw. würdest du es nutzen? 18

    1. Wäre bestimmt nicht schlecht, ich würde es aber kaum nutzen. (10) 56%
    2. Finde ich schwachsinnig. Datentypen haben in AutoIt nichts verloren. (6) 33%
    3. Generell ja, aber nicht nach dem beschriebenen Schema. (1) 6%
    4. Was ist ein Datentyp? Kann man das essen? (1) 6%
    5. Ja, finde ich fast schon notwendig für AutoIt! (0) 0%
    6. Ja, finde ich gut, und werde ich auch nutzen. (0) 0%

    Hallo,

    ich möchte mal kurz etwas vorstellen, und nebenher fragen, was die Allgemeinheit davon hält:
    Nämlich das Prinzip der Datentypen in AutoIt, nach dieser Liste (mit kleinen Modifikationen).

    Klingt zunächst einmal sehr... Utopisch. Etwas, was die Dev's aus dem EN-Forum wohl niemals freiwillig implementieren würden.
    Da wir den AutoIt-Source nicht haben, können wir das auch nicht selber in die Hand nehmen. Wir müssen also an einer anderen Stelle ansetzen, wo wir AutoIt indirekt beeinflussen können: SciTE. :party:

    Damit haben wir natürlich von AutoIt aus keine Datentypen - allerdings für die Seite des Programmierers, was trotzdem ungemein bei der Fehlersuche und auch bei der Ordentlichkeit helfen kann. Daher auch die Bezeichnung Pseudo-Datentypen.

    Realisiert würde das - wie bereits gesagt - über ein SciTE-Plugin, welches per Tastenkombination überprüft, ob im gerade geöffneten Skript auf Typenkonventionen geachtet wurde, und dann ggf. die Verletzungen der Regeln in der Konsole anprangert.

    Ein wichtiger Punkt bei einem solchen Unternehmen ist natürlich die Einbindung in das restliche AutoIt-Schema. Es müssen z.B. auch alle Rückgabewerte der internen Funktionen dokumentiert werden, und generell muss auf viel Syntaktisches geachtet werden. Im derzeitigen Stadium wird nur die Überprüfung einer Zuweisung unterstützt, also z.B. $var = 42.

    Doch wie bestimmt man den Datentyp? Aus C kennt man solche Initialisierungen:

    Code
    int i;


    Doch wenn wir dieses Schema in AutoIt nutzen würden, könnte ein Benutzer ohne dieses PlugIn das Skript nicht mehr ausführen.

    [autoit]


    int $i

    [/autoit]

    Möglich wäre natürlich ein Kommentar hinter der Variable:

    [autoit]


    $i = 42 ;int

    [/autoit]


    Aber das ist nicht sehr intuitiv nutzbar.

    Darum habe ich mich für die Möglichkeit entschieden, die wir sowieso schon nutzen, und die ich für sehr intuitiv halte: Die Bestimmung des Datentypes über den ersten Buchstaben des Variablennamens.
    Präfixgesteuerte Datentypen!

    [autoit]


    $i = 42

    [/autoit]

    Hier ein Beispielskript:

    Spoiler anzeigen
    [autoit]


    $hWnd = GUICreate("Test", 100, 100)

    [/autoit] [autoit][/autoit] [autoit]

    $cCheck1 = GUICtrlCreateCheckbox("Check 1", 10, 10)
    $sCheck2 = GUICtrlCreateCheckbox("Check 2", 10, 30)
    $cCheck3 = GUICtrlCreateCheckbox("Check 3", 10, 50)

    [/autoit] [autoit][/autoit] [autoit]

    $cResult = GUICtrlCreateButton("Auswerten", 10, 70, 80)

    [/autoit] [autoit][/autoit] [autoit]

    GUISetState()

    [/autoit] [autoit][/autoit] [autoit]

    While 1
    Switch GUIGetMsg()
    Case -3
    Exit
    EndSwitch
    WEnd

    [/autoit]

    Wenn ich nun per Strg+Alt+T die Überprüfung starte, bekomme ich folgenden Output in der Konsole:

    Code
    Handle in Zeile 1 ($hWnd), Zuweisung ist vom Typ Handle
    Control in Zeile 3 ($cCheck1), Zuweisung ist vom Typ Control
    !> Typenfehler: String in Zeile 4 ($sCheck2), Zuweisung ist vom Typ Control
    Control in Zeile 5 ($cCheck3), Zuweisung ist vom Typ Control
    Control in Zeile 7 ($cResult), Zuweisung ist vom Typ Control


    (Mit gewissen Einstellungen kann man z.B. nur die Fehler anzeigen lassen)

    Und siehe da, in Zeile 4 ist ein Fehler. :P

    Mir persönlich gefällt dieses Prinzip sehr gut. Jetzt würde mich interessieren, was das Forum davon hält.
    Veröffentlichen möchte ich es im Moment noch nicht. Dazu bin ich noch nicht weit genug, obwohl es grundlegend ja eigentlich einfach ist. ^^

    Fragen, Anregungen und Kritik sind - wie immer - willkommen. ;)

    Gruß

    chesstiger

  • Mh, eigentlich eine feine Sache, würde vl. helfen meine Scripte, deren Variablennamen meist aus irgendeinem Deutsch-Englische Gewurstel bestehen, im Nachhinein einfacher lesbar zu machen. Ich hege nur Zweifel daran, ob ich während des Programmierens die Disziplin hätte, das durchzuzuiehen ^^.

  • Hi,
    um eine "Überprüfung" des Scriptes auf die "richtigen" Datentypen nach deiner Idee zu machen, braucht es kein Lua, da reicht ein einfaches AutoIt-Script.
    Dieses könnten dann interessierte User auch auf ihre eigenen Bedürfnisse umstricken...

    Weiterhin muss ich sagen, dass ich beim Scripten in AutoIt sehr gerne auf Datentypen verzichte. Wohl deshalb, weil der "falsche" Datentyp erfahrungsgemäß im <1%-Bereich meiner Fehler liegt. Um Dll´s anzusprechen oder in asm zu programmieren sind die richtigen Datentypen natürlich erforderlich, allerdings werden dort von mir zu 90% Structs verwendet, welche sowieso einen expliziten Datentyp verlangen.

    Zusammenfassend: ich brauche Datentypen in AutoIt nicht, wozu auch?
    Generell finde ich den Weg, den AutoIt in den letzten Jahren genommen hat, bedenklich! Die Entwicklung geht von einer EINFACHEN, GUT LESBAREN Scriptspracche, zu einem C-Derivat mit allen seinen Nachteilen.
    Da stellt sich mir die Frage, welches Klientel mit AutoIt angesprochen werden soll?

    Wenn ich dagegen sehe, dass 50% der in meiner Firma in den letzten Jahren von mir erstellten Scripte nach der Installation der 3.3.10.0 mit ellenlangen Fehlermeldungen aufwarten, oder (viel schlimmer) einfach falsche oder garkeine Daten zurückgeben, dann läuft etwas gewaltig schief!
    Und dann kommt einer mit Datentypen... :rofl:

  • dito :D

    Ich hatte AutoIt damals auch nur gelernt, weil es wirklich einfach zu verstehen war.
    Und vor allem musste ich mir NULL Gedanken machen über Datentypen.
    Du kannst meinetwegen dein Vorhaben in die Tat umsetzen, aber ob's dann wer nutzt ist die nächste Frage.
    Wenn wir nur 1% der Skripte hier im Forum dann damit durchgehen würden... Oha xD

    • Offizieller Beitrag

    Ich finde Datentypen auch überflüssig!
    Auch wenn es manchmal Fehler gibt bei der automatischen Umwandlung, so ist es doch insgesamt gesehen sehr praktisch, dass man sich nicht darum kümmern muss.
    Diesen Weg hin zu C(++) sehe ich auch skeptisch entgegen. Die Lesbarkeit leidet doch sehr darunter. Wenn ich mir dann noch vorstelle, wie einige hier mit ihrem Spaghetticode jetzt auch noch die neuen "Fähigkeiten" ausnutzen, dann braucht es keinen Obfuscator mehr... :S

    • Offizieller Beitrag

    Ich persönlich halte ein derartiges Unterfangen für wenig sinnvoll.
    Denn du prüfst ja nur, was du selbst festgelegt hast - doch dabei treten sicher die wenigsten Fehler auf. Wenn man sich dazu durchgerungen hat, seine Variablen im Vorfeld zu deklarieren, macht man sich auch ausreichend Gedanken über deren Anwendung.
    Probleme sind doch eher derart, dass man z.B. in einer INI einen Zustand mit 0/1 abspeichert um mit einer direkten IF-Abfrage (If $Zustand Then .. ) darauf zuzugreifen und nicht bedenkt, dass eine INI immer Textwerte zurückgibt, der gelesene Wert vor der Verwendung also noch mit Number gewandelt werden muss.

    Natürlich kannst du das Erstellen und wer mag kann es auch einbinden. Ich würde dir dann auch mal einen Blick hierauf empfehlen. In wesentlichen Komponenten wäre dieses Skript für dein Unterfangen nutzbar.

    Als ich mit AutoIt anfing, war ich ziemlich verwirrt, wegen der fehlenden Variableninitialisierung. Das kannte ich bisher nicht. Ich bin nach wie vor nicht glücklich über den Datentyp Variant und würde eine saubere Typzuweisung bevorzugen, habe mich aber mit dem Zustand arrangiert. Ein Schritt vom Jetzt-Zustand weg würde eh zu Script-Braking-Chances ohne Ende führen. Ich muss mich aber auch Andy's Bedenken anschliessen, was die Entwicklung von AutoIt angeht. Sicher ergeben einige Syntaxänderungen in der akt. Version ein nettes Handling. Aber wie wäre es, wenn man vorhandene Fehler mal vorher beseitigt? Immer wieder werden Bug-Meldungen sofort geschlossen mit dem Verweis: Fixed in next Stable/Beta. Und wenn die Version dann auf dem Markt ist, hat sich absolut nichts geändert!

  • So, dann wollen wir mal antworten. :D

    @Cheater
    Klar, man muss das dann auch konsequent durchziehen. Sonst bringt das nichts. ^^

    Andy

    Code
    command.name.37.$(au3)=Datatypes
    command.37.*.au3="$(autoit3dir)\autoit3.exe" "$(SciteDefaultHome)\Datatypes\Datatypes.au3" "$(FilePath)"
    command.mode.37.*=savebefore:yes
    command.shortcut.37.*.au3=Ctrl+Alt+T


    Zitat aus meiner SciTEUser.properties... Das ist dann auch alles, wofür Lua genutzt wird. Sonst ist das ein AutoIt-Skript.^^
    Gut, das ist ja das schöne: Es ist nicht zwingend, sondern optional nutzbar. Daher müssen Anfänger sich mit sowas nicht belasten.
    Und zum Beispiel für Sachen wie der Hex-Bug würde das schon helfen... Wenn man das ganze dementsprechend erweitert.

    @Make
    Du musstest dir keine Gedanken machen, richtig... Hat auch bestimmt einige Fehler produziert. :D
    Aber von dir z.B. weiß ich ja, dass du auch gerne mit C und C++ programmierst. Gerade deswegen, um bei dieser "Formsache" näher an C dran zu sein, finde ich das sinnvoll. Mir zumindest fällt es zunehmend schwerer, von den primitiven Datentypen in C, den Klassen in C#/D/Java ( :thumbdown: ) und Variant in AutoIt hin und her zu wechseln. Das führt bei mir hin und wieder zu ein paar abenteuerlichen Code-Konstruktionen, vorallem in C, weil dann wildes hin und her Casten kommt. ^^

    Oscar
    Die automatische Umwandlung bleibt ja. Es geht, wie schon gesagt, eher um die Ordentlichkeit des Programmierers, und nur sekundär um Debugging. ^^
    Generell finde ich diesen Weg gut... Solange dabei die eigentlichen Möglichkeiten von AutoIt erhalten bleiben. Beim Erzwingen von Datentypen z.B... wäre ich auch nicht dabei gewesen.
    Diese C-Style Neuerungen gehören alle in den Bereich der Funktion Opt. :whistling:
    Aber grundsätzlich finde ich es nicht schlecht, dass sie vorhanden sind, solange eben die Nutzung nicht erzwungen wird.

    BugFix
    Das wäre ja so leicht erkennbar!

    Beispiel
    [autoit]


    $bZustand = IniRead("test.ini", "config", "zustand", False)

    [/autoit] [autoit][/autoit] [autoit]

    If $bZustand Then
    MsgBox(0, "", "Zustand!")
    EndIf

    [/autoit]
    Code
    !> Typenfehler: Boolean in Zeile 1 ($bZustand), Zuweisung ist vom Typ String

    Die direkte Überprüfung des Ausdrucks (Also nach If <Ausdruck> Then) steht natürlich auch noch an... Aber erst später.
    Und um die Skript-Breaking-Changes zu verhindern, benutze ich ja die Präfixe. Dadurch laufen die Skripte auch ohne das PlugIn. Das PlugIn greift ja sowieso nicht in das Skript ein. Es funktioniert unabhängig vom Ausführen unmittelbar davor. ^^

    Und was den Weg von AutoIt angeht... Solange keiner von uns in's Dev Team kommt, haben wir wohl leider keine Chance, da etwas zu ändern...

    Gruß
    chess

  • Ich finde es immer schön, wenn etwas komplexer wird :D
    Meistens sind solche Sachen Optional.

    Durch die Structansprache via .Element sind in Autoit feste Datentypen sehr leicht nutzbar.

    [autoit]

    Local $int = DllStructCreate('int i;int Square'), $float = DllStructCreate('float Root')
    For $i = 0 To 9 Step 1
    $int.i = $i
    $int.Square = $int.i^2
    $float.Root = $int.i^0.5
    ConsoleWrite($int.Square + $float.Root & @CRLF)
    Next

    [/autoit]

    Die Schreibweise ist zwar unschön (und man kann For auch kein $int.i als Zähler zuweisen) aber absolut Typensicher.
    Von daher ist Typensicherheit optional schon integriert und meiner Meinung nach eine externe überprüfung überflüssig.

    lg
    M

  • Ich kann mich dem was schon genannt wurde eigentlich nur anschließen, Datentypen verbessern die Sprache jetzt nicht wirklich.
    Sofern die Scripte schneller laufen - okay - dann wäre ich einverstanden aber so viel wird es jetzt glaube ich nicht bringen.
    Stattdessen sollte man einfach die Präfixe hinschreiben, oder jeder sollte sich seinen eigenen Stil suchen.