[patch] devspec2array case insensitivity

[Phill]

Hallo, nur ein Vorschlag. Es muss sich ziemlich verbogen werden, u.a. zugriff auf %defs direkt, wenn man die Groß-/Kleinschreibung ignorieren möchte.

Mit dem Patch würden zwei neue Operatoren eingeführt werden, ( ~ und !~ ) die das Problem lösen könnten.

Oder ist das doch irgendwie anders machbar?

Gruß

[rudolfkoenig]

Warum moechte man Gross-/Kleinschreibung ignorieren?

[Phill]

Stimmt das hätte eigentlich dazu gehört. Sorry.

Also ich versuche konsequent alles klein zu schreiben, das gelingt mir zwar nicht immer, aber meistens. Bei Räumen z.b. sieht es blöd aus.
Meine Homeatic Geräte habe ich hm_ vorangestellt. Neue Geräte haben aber HM vorangestellt.
Leider sind die Modulnamen sehr inkonsequent was der Camel Case-Notation angeht. Um nach "TYPE" zu filtern muss immer erst die genaue Schreibweise bekannt werden.
Wäre auch hilfreich bei Userattributen deren Werte manuell eingetragen werden. Da herrscht bei vielen bestimmt chaos.
Spracherkennung ist ja immer mehr ein Thema, hier kann auch nicht davon ausgegangen werden das der Raum immer richtig übermittelt wird. Gerade im englischen da kommen die Räume dann klein obwohl sie vermutlich groß geschrieben sind.
Die Werte von Readings und State sind meistens klein geschrieben. Es gibt aber ausnahmen. Initialized gibt es bei mir groß und klein.
Ist auszuschließen das Werte die von externen Geräten (auch Webseiten) kommen, immer klein geschrieben sind und in das Schema passen?
Und wenn es dem Anwender nur hilft Geräte zu lokalisieren die vom eigentlichen Namensschema abweichen, um sie dann zu korrigieren.

Ich sehe aber auch keine Nachteile. Man kann zwar nicht ausschließen das es Anwender gibt die gleiche Namen mit unterschiedlicher Groß-Kleinschreibung haben, aber bestehende Konfigurationen sind ja nicht betroffen da = und != wie nicht angefasst sind.
Würde es zu mehr Gleichgültigkeit  bezüglich Groß-/Klein Ordnung führen? Vielleicht! Wäre das schlimm?

Gruß

[rudolfkoenig]

Würde es zu mehr Gleichgültigkeit  bezüglich Groß-/Klein Ordnung führen? Vielleicht! Wäre das schlimm?

Ja.
Wenn man irgendwo "list abc" eingibt, und stillschweigend die Daten von ABC kriegt, dann erwartet man, dass ReadingsVal(abc), AttrVal(abc), etc auch funktioniert. Konsequenterweise darf man auch keine GeraeteNamen/Attributnamen/Readingnamen/etc zulassen, die nach einem lc() gleich sind. Als naechsten Schritt koennte man alle Grossbuchstaben abschaffen, sind ja eh ueberfluessig.

Abgesehen davon, dass ich meine Grossbuchstaben behalten will, muesste man ziemlich viel Ubauen, und viele Benutzer veraergern.

[Phill]

Aber das ist doch hier nicht stillschweigend umgesetzt! Man müsste doch aktiv list NAME~abc eingeben.
list abc würde weiterhin nicht ABC zurückgeben.
Ich will ja die Groß-/Kleinunterscheidung hier nicht abschaffen.

[rudolfkoenig]

Aber das ist doch hier nicht stillschweigend umgesetzt! Man müsste doch aktiv list NAME~abc eingeben.

Daran sieht man, dass man den Patch anschauen sollte, bevor man anfaengt zu laestern.

Hab dein Patch eingecheckt. Bitte das naechste mal in der Doku kein UTF-8, sondern die HTML-Entities (ß, etc) verwenden. Sonst war dein Patch perfekt

[betateilchen]

Schon wieder so eine unsägliche Änderung, die nicht zuende gedacht wurde.

Angenommen, es gäbe zwei Module, die sich in ihrem Namen nur in der Groß-/Kleinschreibung einzelner Buchstaben unterscheiden. Dann kann die jetzt vorgenommene Änderung durch ihr Gleichhobeln nach dem Motto "scheiß auf die Groß-/Kleinschreibung" zu unvorhersehbaren Ergebnissen führen.

Leider sind die Modulnamen sehr inkonsequent was der Camel Case-Notation angeht.

Das ist eine sehr kühne Behauptung. Hast Du mal darüber nachgedacht, dass es aus Sicht des Modulautors vielleicht tatsächlich einen Grund geben könnte, genau so vorzugehen und zu bezeichnen, wie er es in seinem Modul getan hat?

Oder geht es hier einmal mehr nur um den von mir schon mehrfach angeprangerten, um sich greifenden Egoismus einzelner Entwickler, die einfach ihren Dickkopf durchsetzen wollen, ohne Rücksicht auf andere Entwickler zu nehmen?

Um nach "TYPE" zu filtern muss immer erst die genaue Schreibweise bekannt werden.

Ja. Und das ist auch gut so.

Meine dringende Bitte: die jetzt vorgenommene Änderung wieder ausbauen, damit ich mich als Modulautor auch weiterhin darauf verlassen kann, dass FHEM die Module "configDB" und "configdb" jederzeit und überall zweifelsfrei auseinanderhalten kann.

Danke.

[Phill]

Daran sieht man, dass man den Patch anschauen sollte, bevor man anfaengt zu laestern.

Hast du dich daran gehalten?

Angenommen, es gäbe zwei Module, die sich in ihrem Namen nur in der Groß-/Kleinschreibung einzelner Buchstaben unterscheiden. Dann kann die jetzt vorgenommene Änderung durch ihr Gleichhobeln nach dem Motto "scheiß auf die Groß-/Kleinschreibung" zu unvorhersehbaren Ergebnissen führen.

Es ändert nichts an bestehenden mechanismen. An der Differenzierung der Groß-Kleinschreibung hat sich nichts geändert. Es ist ein "neues" Feature hinzugekommen.

Und auch diesmal muss ich den Vorwurf eines Egoismus meiner seits zurück weisen. Bitte nicht Rückgängig machen. Es wird überhaupt keine Probleme verursachen.

[herrmannj]

Ich teile Betateilchens Einwände. In einigen Monaten blickt wieder keiner mehr durch wann case intensiv / wann nicht. Als nächstes wird das dann mit Syntaxvariante x+ auf redings und devspec ausgeweitet (warum geht das dort und da nicht ... ).

Am Ende wundern sich alle warum es noch komplexer wird.

Ich hätte gern eine Autokorrektur für attribute. Nervt einfach das es nicht geht wenn ich mich vertippe. (Kopfschüttel....)

[Phill]

Als nächstes wird das dann mit Syntaxvariante x+ auf redings und devspec ausgeweitet (warum geht das dort und da nicht ... ).

Was meinst du damit? Die "devspec" ist doch jetzt allgemein gültig mächtiger geworden.
Und bei ReadingsVal und co. macht es keinen Sinn, da hier keine Mengen abgehandelt werden.

[rudolfkoenig]

@betateilchen/@herrmannj: habt ihr den Patch angeschaut?

[betateilchen]

Die "devspec" ist doch jetzt allgemein gültig mächtiger geworden.

devspec und die GROSS-/kleinschreibung sind zwei der fundamentalen Grundpfeiler von FHEM, die an vielen Stellen verwendet werden.

Allein durch den Einbau der MÖGLICHKEIT, eine case-insensitive Verarbeitung zu bekommen, wird an beiden dieser Grundpfeiler gerüttelt. Wozu? Wo ist der tatsächliche Mehrwert? Was kann ich damit jetzt MEHR machen als vorher?

devspec ist nicht "allgemein gültig mächtiger" geworden, sondern es unterstützt jetzt noch mehr die Bequemlichkeit, Faulheit und oft auch Unwissenheit der Anwender, die jetzt noch weniger denken und verstehen müssen, was sie tun als vorher.

@betateilchen/@herrmannj: habt ihr den Patch angeschaut?

Ja. Und ich habe mir Gedanken über seine möglichen Auswirkungen gemacht.

[CoolTux]

Treffender hätte ich es nicht sagen können.

Ich muss gestehen das ich erst ein Befürworter des Patches war. Die Idee hat mir gefallen. Wenn man dann aber erstmal länger darüber nach denkt, während man den Code des Patches vor sich hat, kommen doch genügend Bedenken auf um den Patch zu verwerfen.


Daher auch von meiner Seite
DAGEGEN



Grüße

[Phill]

Auch auf die Gefahr hin das ich wieder einer Diffamierung ausgesetzt werde, gehe ich doch weiter auf die Diskussion ein. Es ist ja schon fast so das man hier Angst haben muss zu Antworten.

@betateilchen

devspec und die GROSS-/kleinschreibung sind zwei der fundamentalen Grundpfeiler von FHEM, die an vielen Stellen verwendet werden.

devspec ja. Die Unterscheidung der Groß-/Kleinschreibung ist eine fundamentaler Grundsatz von Linux. In der "menschlichen" Welt haben diese Buchstaben eben einen Zusammenhang. Und der muss der Maschine erst beigebracht werden.

Allein durch den Einbau der MÖGLICHKEIT, eine case-insensitive Verarbeitung zu bekommen, wird an beiden dieser Grundpfeiler gerüttelt.

Wird es nicht, da es nicht die beiden Grundpfeiler sind.

Wozu? Wo ist der tatsächliche Mehrwert? Was kann ich damit jetzt MEHR machen als vorher?

Hab ich im 3. Beitrag mal zusammengefasst.

devspec ist nicht "allgemein gültig mächtiger" geworden, sondern es unterstützt jetzt noch mehr die Bequemlichkeit, Faulheit und oft auch Unwissenheit der Anwender,

Doch ist es, es unterstützt eine neue Möglichkeit der Mengenbildung und daher ist es mächtiger geworden. Und an Anwender zu unterstützen, ist ja mal absolut nichts schlechtes.
Andernfalls entfernen wir jetzt mal ganz schnell die RegExpfähigkeit der devspec, weil es würde ja auch ohne gehen. Übrigens ist die CaseInsensitivity eine Option dieser RegEx. Wenn die Perl Entwickler das so für Abwegig gehalten hätten gebe es diese Option wohl nicht. Ist doch nur eine Bequemlichkeit für die Anwender. Schwachsinn.

unterstützt jetzt noch mehr die [...] Unwissenheit der Anwender die jetzt noch weniger denken und verstehen müssen, was sie tun als vorher.

Wenn du das für schlecht hälst, wiederspricht sich das komplett mit deinen Worten aus einem anderen Beitrag.

[...] FHEM bald zu einem unbedienbaren Moloch verkommt

Du willst also das diese unbedarften Anwender direkt auf %defs zugreifen wenn sie auf so ein Problem stoßen. Das ist natürlich schlau.

Man kann es sich nicht einfach immer mit irgendwelchen fadenscheinigen Argumenten so hinlegen wie man möchte. Es gibt die Probleme und nur weil du sie nicht hast, heißt das nicht das kein anderer diese nicht auch haben darf.

Klar würde das auch über ein cmdalias gelöst werden aber ich würde halt gerne eine Entwicklung in FHEM sehen. Und du hast hier noch nicht einen belegbaren Hinweis auf ein tatsächliches Problem mir diesem Patch dargelegt.

Übrigens eine der Diskussionen die im Zusammenhang mit dem Thema hatte:https://forum.fhem.de/index.php/topic,82442.msg751852.html#msg751852
Hier geht es tatsächlich um Bequemlichkeit, aber wie gesagt die Probleme treten auf.

[Benni]

Hallo zusammen,

eigentlich wollte ich mich hierzu erst gar nicht äußern, weil mir das Thema nicht wichtig genug war.
Nachdem ich aber eben freundlicherweise per PM darum gebeten wurde, gebe ich auch mal noch meinen Senf dazu.

Im Prinzip sehe ich das ähnlich wie betateilchen und die anderen: Ich kann keinen vernünftig begründeten Anwendungsfall erkennen, auch nicht anhand der Ausführungen deinem Beitrag in #3.
Und wenn ich mir deinen letzten Beitrag anschaue, scheinen dir selbst keine echten Argumente mehr einzufallen, die dafür sprechen.

Das einzige was hier m.E. unterstützt wird, ist die Fauhlheit, bzw. eigene Inkonsequenz der User an anderer Stelle.
Nämlich, bspw. bei der Benennung Ihrer Devices, der Zuordnung in Gruppen oder Räumen oder sonst irgendwie. Möglichkeiten zur Device-Gruppierung gibt es ja unzählige.
Ich sehe hier auch eher die Gefahr, dass diese Bequemlichkeitsunterstützung auch an anderen Stellen gefordert wird und am Schluss keiner mehr durchblickt, bzw. man sich plötzlich nicht mehr auf die einfachsten Dinge verlassen kann.

Das waren meine 2 Ct.!
Wie gesagt, das Thema ist mir eigentlich nicht wichtig genug, allerdings war meine Tendenz bereits von Anfang an eher dagegen.

Gruß Benni.

[Phill]

Ich wollte ja auch nichts anderes als deine hoch geschätzte Meinung dazu wissen. Vielen Dank.

[betateilchen]

Nachdem ich aber eben freundlicherweise per PM darum gebeten wurde

wie cool ist DAS denn? Da gebe ich doch gleich mal eine Runde Popcorn aus!

Wird es nicht, da es nicht die beiden Grundpfeiler sind.

Ich hatte auch nicht geschrieben, dass "die beiden" Grundpfeiler von FHEM sind, sondern darauf hingewiesen, dass es zwei (von vielen) Grundpfeilern sind, die ein verlässliches Fundament bilden, auf das man sich bisher verlassen konnte.

Du willst also das diese unbedarften Anwender direkt auf %defs zugreifen

Der "unbedarfte Anwender" weiß überhaupt nichts von %defs und er braucht davon auch nichts zu wissen.

Und du hast hier noch nicht einen belegbaren Hinweis auf ein tatsächliches Problem mir diesem Patch dargelegt.

Und Du scheinst immer noch nicht verstanden habe, worum es hier in der Diskussion überhaupt geht. Es geht nicht um den Patch an sich, sondern um eine grundlegende Verhaltensänderung innerhalb des FHEM-Kerns, für die es keinerlei nachvollziehbaren Grund oder schlüssige Rechtfertigung gibt.



Übrigens - das hier:

damit ich mich als Modulautor auch weiterhin darauf verlassen kann, dass FHEM die Module "configDB" und "configdb" jederzeit und überall zweifelsfrei auseinanderhalten kann.

ist keine Fiktion oder theoretische Betrachtung, sondern seit Jahren Realität in FHEM. Diese beiden Module gibt es in diesen beiden unterschiedlichen Schreibweisen wirklich. Und das ist in keinster Weise

inkonsequent was der Camel Case-Notation angeht.

sondern es war seinerzeit eine lange und wohl überlegte Entscheidung, das genau so zu tun.

[RoBra81]

Hallo,

Soweit ich das sehe, wird hier ein neuer Operator eingeführt, der genutzt werden kann, aber nicht genutzt werden muss. Daher sehe ich erstmal nix, was dagegen sprechen könnte. Das Argument "der Nutzer könnte sich diese Bequemlichkeit/Vereinfachung auch an andere Stelle wünschen" halte ich für ziemlich abstrus: ja, es kann passieren, dass Nutzer sich sowas wünschen. Wenn sich keiner findet, der es umsetzt, bleibt es eben ein Wunsch. Und wenn sich jemand findet oder der Nutzer selbst einen entsprechenden akzeptierten Patch bereit stellt, wird FHEM kontinuierlich verbessert.

Wie gesagt, wenn die neue Funktion ein KANN aber kein MUSS mit umfangreichen Konsequenzen ist, spricht doch nichts dagegen, im FHEM neue Funktionen hinzuzufügen...

Just my 2 ct.

Ronny

[betateilchen]

Genau das KANN ist aber hier das Problem.

Das Argument "der Nutzer könnte sich diese Bequemlichkeit/Vereinfachung auch an andere Stelle wünschen" halte ich für ziemlich abstrus

Das ist nicht abstrus, sondern beruht auf langen Erfahrungen hier im Forum. Und das glücklicherweise nicht nur bei mir.

[betateilchen]

wird hier ein neuer Operator eingeführt, der genutzt werden kann, aber nicht genutzt werden muss. Daher sehe ich erstmal nix, was dagegen sprechen könnte.
...
wird FHEM kontinuierlich verbessert.

Diese extrem schwache Argumentationskette könnte man auch anderswo verwenden:

• Atombomben wurden gebaut, weil man es konnte.
• Atombomben wurden eingesetzt, weil man sie gebaut hatte und sie einsetzen konnte.

• Man hätte beides nicht gemusst.
• Ob es sich bei der Entwicklung der Atombombe um eine "kontinuierliche Verbesserung" der Waffentechnik handelt, ist für mich bis heute zweifelhaft.

Zugegeben: ein extremes Beispiel für "etwas tun, das man tun kann, aber nicht muss". Aber trotzdem Realität.

[herrmannj]

das Problem ist, dass es en-vogue ist die Anzahl der attribute/syntax-varianten und sonstigen Einstellmöglichkeiten als Maststab zur Bewertung der Qualität zu nehmen. 55.000 müssen(!) doch besser sein als 50 ... geht nicht anders. Leider keine Seltenheit.

[RoBra81]

• Atombomben wurden gebaut, weil man es konnte.
• Atombomben wurden eingesetzt, weil man sie gebaut hatte und sie einsetzen konnte.

Okay, das ist für mich das Totschlagargument, ich bin jetzt auch dafür, dass es wieder ausgebaut wird!!

**Sarkasmus aus**

[rudolfkoenig]

Ich bin erstaunt ueber die starken Emozionen ueber diese neue Moeglichkeit.

Bevor ich als Massenmoerder angeklagt werde, muesste ich dann Folgendes konsequenterweise auch ausbauen:
- Ausfuehren eines Befehls mit falscher Klein-/Grossschreibung (jsonlist2)
- Ausfuehren eines Befehls, wenn es noch nicht komplett eingetippt wurde (li)
- Definieren eines Geraetes mit falscher Klein-/Grossschreibung (define a AT 00:00 shutdown)
- .* in devspec2array

Ich gehe davon aus, dass wenn ich das alles entferne, etliche Benutzer-"Einzeiler" nicht mehr funktionieren werden.

[herrmannj]

Ich gehe davon aus, dass wenn ich das alles entferne, etliche Benutzer-"Einzeiler" nicht mehr funktionieren werden.

die logische Folge von, .... gut gemeinten .... , "features".

Also nochmal zurück zu "schadet doch keinem":

Heute "schadet doch keinem"...
morgen "oh, da müssen wir anderes nachziehen"...
übermorgen "shit! das bekommen wir nicht mehr zurückgedreht " ...

* Mathematik: "1+2" ergibt "3". Immer*! Ohne wenn und aber (*um Vorzubeugen: dezimalsystem )
* Fhem: unterscheidet Groß- und Kleinschreibung. Immer. Also außer hier... und da. Naja. Und dort. Aber an anderer Stelle nicht !!!

thanks for the prove

[betateilchen]

die logische Folge von, .... gut gemeinten .... , "features".

Danke. Die Aussagen von Jörg kann ich zu 100% unterschreiben.

Bevor ich als Massenmoerder angeklagt werde, muesste ich dann Folgendes konsequenterweise auch ausbauen:

Zumindest die Punkte 1 und 3 aus Deiner Aufzählung fand ich schon immer kacke fragwürdig.

Deshalb muss man die Menge solchen Mists aber nicht noch unnötig vergrößern.

[KernSani]

Mal 2 ct von meiner Seite: Anwendungsfälle bei denen eine case-insensitivity Sinn macht beschränken sich aus meiner Sicht auf Attribut-Werte und ggf. Readings-Werte. Alles andere wäre meiner Meinung nach nur mit Faulheit zu begründen (zumindest ist mir bisher nix eingefallen)


Kurz, weil mobil...

[rudolfkoenig]

Zumindest die Punkte 1 und 3 aus Deiner Aufzählung fand ich schon immer kacke fragwürdig.

Die sind seit sehr lange drin, und sind (wenn ich micht recht erinnere) ein Nebeneffekt der Windows "Portierung".

[betateilchen]

Nachdem sich die eindeutige Mehrheit der Entwickler, die sich hier im Thread geäußert haben, gegen die durchgeführte Änderung ausgesprochen habe, frage ich mich seit Tagen, was denn nun mit dem unsäglichen patch passiert?

Eigentlich hatte ich erwartet, dass die Änderung schnellstens wieder ausgebaut wird.

[dev0]

Ich habe das nicht erwartet oder gab es eine, vom Maintainer initiierte, Abstimmung darüber?