[patch] devspec2array case insensitivity

[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?