Parameter in Date.au3 nicht wie in der Norm

    • Offizieller Beitrag

    Schaut mal bitte in diesen Thread (Post #6 ff.). Hier geht es um die Diskussion der richtigen Darstellung von Minuten (mm oder nn).

    Es sollte bitte niemand aus der Implementierung der Minutenangabe in der Date.au3 als n ableiten, dass dieses die gültige Minutendarstellung ist. Hier hat Jos einfach nur den bequemsten Weg gewählt, und um eine Unterscheidung von Groß- und Kleinschreibung zu sparen, den Parameter n für Minutenrechnung festgelegt. DAS ist aber ausschliesslich eine RECHENANWEISUNG und keine normgerechte Minutendarstellung.

    Für Zeitdarstellungen gilt die ISO 8601: hh:mm:ss,f Das f bedeutet: Dezimale Bruchteile (fraction).

    Hätte man sicher in der UDF auch so implementieren können. Doch dem Ersteller stand es ja frei, wie er seine Parameteranweisungen definiert. Für uns ist es nur von Belang zu beachten, dass dieses eben nur für diese UDF gilt.

  • Das ist leider das Problem wenn verschiedene Leute an den UDFs basteln, es gibt generell in den UDFs (bis auf die _GUICtrlxxx_bla Konvention) nichts was UDFs gemeinsam hätten.

    Einige wollen unbedingt Arrayreferenzen, andere akzeptieren auch Kopien. Einige geben Integer zurück und andere Strings und dann sucht man sich die Finger wund.

    Wenn man sich mal die Implementation der _DateDiff in der UDF anschaut könnte man sich eigentlich noch mehr aufregen, weil hier nicht wie vermutet Switch (case-insensitiv) sondern Select verwendet wird!

    Also man hätte direkt die Möglichkeit des case-sensitiven "m"s da, aber sie wird absichtlich nicht genutzt. Das ist schon grob fahrlässig.

    Und das tolle ist ja, die UDF ist mittlerweile so alt, dass sie da garantiert nichts ändern werden, da das wieder 90% der Scripte zerschießt die _DateDiff verwenden.

  • Da wir uns hier im Bereich 'Talk' befinden, darf man ja mal ins Blaue schreiben ;).

    Wie vorangegangenen Diskussionen zu entnehmen ist, stehen wir vor folgender Situation :

    - Jos' Interesse an einer konsequenten Weiterentwicklung von AutoIt ist stark rückläufig. Nun, das ist sein gutes Recht.

    - Der Quellcode von AutoIt ist seit langem kein OpenSource mehr. Die Rechte liegen bei Jos und Freigaben werden nicht erteilt. Das ist, wenn auch meiner Meinung nach in geringerem Maße, ebenfalls sein gutes Recht. 'In geringerem Maße' deshalb, weil vieles von der Community beigesteuert wurde.

    - Einschub :

    Ihr kennt vielleicht den Webserver Mongoose.

    Dieses Projekt stand bis 2013 unter MIT Lizenz, bis der ursprüngliche Entwickler und Rechteinhaber auf eine kommerzielle Lizenzform (GPLv2) umgestiegen ist. Die Community war ob dieser Entscheidung doch etwas angepisst, weil sie über Jahre an der Weiterentwicklung mitgearbeitet hat.

    - Einschub Ende

    Ein Fork ist daher nicht möglich, mal ganz abgesehen davon, wer die Arbeit überhaupt machen soll.

    - diverse Mitstreiter im Blauen Forum haben sich (teilweise frustiert) zurückgezogen oder ihr Engagement heruntergefahren.

    Folge :

    Selbst Ungereimtheiten in häufig verwendeten UDF's (siehe Date.au3) bleiben unbehandelt.

    Natürlich ließen sich Anpassungen (s.o.) in den UDF's machen. Das würde aber zu Inkonsistenzen bei den Hilfen und Quelltexten führen, und zukünftige Updates würden diese Änderungen überschreiben.

    Man hätte quasi eine Parallelwelt.

    Frage :

    Wäre eine AutoIt.de-eigene 'SammelUDF', die die gängigsten Macken mittels Wrapperfunktionen beseitigt, ein gangbarer Weg ? Viele UDF's die auf ...Ex.au3 enden waren ursprünglich ja auch mal Userprojekte, die dann z.T. in die Standardinstallation übernommen wurden.

    Inkonsistenzen wären aber auch damit wohl nicht zu vermeiden.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    • Offizieller Beitrag

    Wäre eine AutoIt.de-eigene 'SammelUDF', die die gängigsten Macken mittels Wrapperfunktionen beseitigt, ein gangbarer Weg ?

    Das halte ich für keine gute Idee!

    Selbst wenn sich jemand findet, der das pflegt, bleibt immer noch, dass man bei jeder Frage hier im Forum nachfragen muss, ob die "AutoIt.de"-UDF oder die originale UDF verwendet wurde.

    Und im Laufe der Zeit wird es dann auch noch verschiedene Versionen der "AutoIt.de"-UDF geben (andere Versionsnummern).

  • Das halte ich für keine gute Idee!

    Ich im Grunde auch nicht, daher :

    Inkonsistenzen wären aber auch damit wohl nicht zu vermeiden.

    Es ist nur schade, dass wir offenbar mit recht trivialen Unzulänglichkeiten leben müssen, obwohl ein Fix (wie bei der Date.au3) jederzeit möglich wäre :(. Na ja, freuen wir uns über das was wir haben.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Hi!

    Das ist leider das Problem wenn verschiedene Leute an den UDFs basteln, es gibt generell in den UDFs (bis auf die _GUICtrlxxx_bla Konvention) nichts was UDFs gemeinsam hätten.

    Einige wollen unbedingt Arrayreferenzen, andere akzeptieren auch Kopien. Einige geben Integer zurück und andere Strings und dann sucht man sich die Finger wund.

    Um es mal in meiner liebreizenden Art auszudrücken: "Wo ist der Bus mit den Leuten drin die DAS interessiert?"

    Eine UDF ist per definitionem eine USER DEFINED FUNCTION. Und dabei liegt der Fokus auf User!

    Und derjenige User, der sich die Arbeit macht und eine Funktion erstellt, mit einem Header ausstattet, und dann "selbstverständlich" nach Jahren noch dafür Support leistet in Form von "...leg mir mal den Arm aus der Sonne und schreib DEINE UDF so um dass ich damit auch noch blablub machen kann..." hat imho das ALLEINIGE Recht die von ihm erstellte Funktion so zu gestalten wie er das für richtig oder auch notwendig hält!

    Es bleibt jedem freigestellt, die *glücklicherweise* allgemein verfügbaren (aka UD-) Funktionen nach eigenem Gusto anzupassen und zu modifizieren.

    Meiner Meinung nach ist es ist der Job der Entwickler, aus den "Unterstrich_Funktionen()" ein einheitliches Konzept zu machen und dieses dann in die "blauen" (internen) AutoIt-Funktionen zu überführen. Dann ist/wäre die "UDF" in einem AutoIt-Update ersetzt durch die dann neue interne Funktion. Aber wer soll DAS denn machen?! Da gibt es wahrlich größere Baustellen in AutoIt :o), und die Zahl der "Developer" dünnt sich auch immer mehr aus....

    Ich für meinen Teil passe regelmäßig die unterschiedlichsten Funktionen an meine individuellen Bedürfnisse an. Daher wächst und gedeiht mein "User Include"-Ordner prächtig ;)

    Und genau so sollte es auch sein!

    Es gibt sowieso genug C&P-"Programmierer" die statt im Wust der (schon erwähnt KOSTENLOS verfügbaren) Funktionen etwas passendes zu suchen einen Thread in einem Forum erstellen, in dem dann eifrige "ichweiswas"-User dann die fertige Funktion (aus dem schon erwähnten Wust) heraussuchen und diese dann auf Nachfrage noch auf die Bedürfnisse des Threaderstellers passend umschreiben. Voila. Ziel erreicht. :Face:

    Und WEHE, es wird auf die Hilfe oder noch schlimmer Google oder die Forensuche verwiesen....;(

    Fazit:

    Eine UDF ist so hinzunehmen wie sie ist. Wer sich berufen fühlt, "Gemeinsamkeiten" in den Aufrufkonventionen an die AutoIt-internen Funktionen anzugleichen/anzupassen, soll das tun und kann diese "Verbesserung" bei den DEV´s einreichen. Ich bin sicher, die sind froh, sollte sich jemand anderes diesem Thema annehmen....und würden das auch gerne in das nächste Update übernehmen8o

  • Um es mal in meiner liebreizenden Art auszudrücken: "Wo ist der Bus mit den Leuten drin die DAS interessiert?"

    :rofl:

    Das war echt witzig. Aber ansonsten finde ich das auch sachlich hundertprozentig richtig.

    Bei dem Startbeispiel, denke ich mir, ich sollte mir einfach jede Funktionsbeschreibung auch anschauen. Solange die UDF tut, was sie da verspricht, wenn ich mich an die Vorgaben halte, ist doch alles gut.

    Grüße autoiter