[patch] devspec2array case insensitivity

Phill · 13 Februar 2018, 11:50:18

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 · 13 Februar 2018, 11:54:21

Warum moechte man Gross-/Kleinschreibung ignorieren?

Phill · 13 Februar 2018, 13:57:41

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 · 13 Februar 2018, 15:10:22

ZitatWü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 · 13 Februar 2018, 15:18:18

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 · 13 Februar 2018, 22:23:55

ZitatAber 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 · 13 Februar 2018, 23:07:26

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.

Zitat von: Phill am 13 Februar 2018, 13:57:41
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?

Zitat von: Phill am 13 Februar 2018, 13:57:41
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 · 13 Februar 2018, 23:28:53

Zitat von: rudolfkoenig am 13 Februar 2018, 22:23:55
Daran sieht man, dass man den Patch anschauen sollte, bevor man anfaengt zu laestern.

Hast du dich daran gehalten?

ZitatAngenommen, 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 · 13 Februar 2018, 23:42:28

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 · 13 Februar 2018, 23:58:41

ZitatAls 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 · 14 Februar 2018, 06:20:24

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

betateilchen · 14 Februar 2018, 09:47:05

Zitat von: Phill am 13 Februar 2018, 23:58:41
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.

Zitat von: rudolfkoenig am 14 Februar 2018, 06:20:24
@betateilchen/@herrmannj: habt ihr den Patch angeschaut?

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

CoolTux · 14 Februar 2018, 10:36:28

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 · 14 Februar 2018, 11:42:39

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

Zitatdevspec 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.

ZitatAllein 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.

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

Hab ich im 3. Beitrag mal zusammengefasst.

Zitatdevspec 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.

Zitatunterstü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.

Zitat[...] 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 · 14 Februar 2018, 12:33:57

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.