[FR] Cachewolfe Suggestions for US users

[Christian und die Wutze]

Nebenbei bemerkt kann das Zentrum eines Profils auch zwischen einigen Caches liegen und daher der Abstand zu mehreren Caches <160 Meter betragen.

Mir persönlich ist es auch egal, aber wenn schon Arbeit in die Konvertierung gesteckt wird, dann sollte das doch auch so umgesetzt werden, dass es auch verwendet wird, oder?

 

[Engywuck]

So, ich habe jetzt mal tabellarisch zusammengestellt, wie verschiedene Werte in verschiedenen Modulen unterschiedlich formatiert werden:

Ort des Geschehens    Input (double)   Output (String)  Output (double)  
-----------------------------------------------------------------------

Liste, diverse            1,6             1,60 km
Exporter                                  1,00 mi.

Filter eingeben            1                                  1,6
Filtermaske setzen         1,6                                 1

Solver: Distance                                             ja
Solver: Project            ja

Goto  Dist                 160            160,000 km
                                          100,000 mi.
                           0,8            800 m
                                          0,500 mi.
                           0,08           80 m
                                          263 ft
      Speed                160            160 km/h
                                          100 mph
                           0,8             0,8 km/h
                                           0,5 mph
                           0,08            0,1 km/h
                                           0,0 mph

Wenn jetzt jemand einen Vorschlag machen möchte, wie man den Output so geradebügelt, dass er für alle Fälle passt...? Dann könnte man das bequem in eine zentrale Funktion auslagern, bzw. in derer zweie - einmal für String und einmal für Double-Output.

Gruß, E.

 

[pfeffer]

man könnte eine Funktion machen, die 2 Rückgabewerte (entweder als Klasse oder als Array) hat:
1. die zahl als double
2. die Einheit als Int

Darauf aufbauend weitere Funktionen
* getDistanceLocale(double dist) as string 'dist in km
* getSpeedLocale(doube speed) as string 'speed in km/h

Bei der Konvertierung String -> Double umgekehrt.

Gruß,
Pfeffer.

EDIT: auf englisch ist natürlich auch das richtige Dezimaltrennzeichen ("." )zu verwenden.
EDIT2: evtl. müssten die get...-methoden noch nen 2 Parameter für die gewünschte Präzision (Anzahl Nachkommastellen bei miles / km) bekommen.

 

[Engywuck]

Deswegen hatten Pfeffer und ich vorgeschlagen, als Du Dein Konzept vorgestellt hast, eine solche Funktion für alle Stellen zu implementieren.

Nicht dass der Eindruck entsteht, dass ich Euch ignorieren wollte: Diesen Teil hatte ich anders verstanden, nämlich in dem Sinne, dass es nur eine Stelle gibt, die die nummerischen Umrechnungen durchführt. Das ist ja auch (im wesentlichen) so.

Das hat auch nichts mit Code-Sparen sondern mit besserer Wartbarkeit zu tun.

Oh, auch da wüsste ich ein paar Stellen (eine ganz spontan), bei denen man bezüglich Wartbarkeit Ekelpickel bekommt. Die eine Stelle hat schon dazu geführt, dass wir Funktionalität zurückfahren mussten, weil wir das nicht mehr im Griff hatten. Da müsste man mal mit dem eisernen Besen durchkehren... Aber das erst, wenn EVE entweder aktiv oder Geschichte ist.

Gruß, E.

 

[pfeffer]

Das hat auch nichts mit Code-Sparen sondern mit besserer Wartbarkeit zu tun.

Oh, auch da wüsste ich ein paar Stellen (eine ganz spontan), bei denen man bezüglich Wartbarkeit Ekelpickel bekommt. Die eine Stelle hat schon dazu geführt, dass wir Funktionalität zurückfahren mussten, weil wir das nicht mehr im Griff hatten. Da müsste man mal mit dem eisernen Besen durchkehren... Aber das erst, wenn EVE entweder aktiv oder Geschichte ist.[/quote]ja, allerdings!

Gruß,
Pfeffer.

 

[Silas]

Nur weil Refactoring allgemein von Nöten ist, sollte man nicht weiterhin Code schreiben, der eigentlich sofort überarbeitet gehört.

Meiner Meinung (also der eines Außenstehenden) nach gehört die genannte Funktionalität auf jeden Fall in eine Klasse, die dann auch über eine eindeutige Verantwortlichkeit verfügt. Wenn sich die Funktionalität halt nicht mit einer Methode implementieren lässt (weil sie zu umfangreich ist oder -- wie hier -- die Anforderungen zu unterschiedlich sind), kommen eben mehrere Methoden für die unterschiedlichen Fälle in die neue Klasse, die sich dann ggf. auch noch Teilfunktionalitäten in Form privater Methoden teilen können.

Das nur so ganz allgemein als gut gemeinter Ratschlag am Rande. Mir ist natürlich klar, dass das eigentlich eine Entwicklunger-interne Diskussion ist

Grüße, Silas

 

[Engywuck]

Nur weil Refactoring allgemein von Nöten ist, sollte man nicht weiterhin Code schreiben, der eigentlich sofort überarbeitet gehört.

Damit hast Du natürlich recht. Wenn Du dann jedoch der Meinung bist, dass der vor mir geschriebene Code dazu gehört, so muss ich dem doch entgegentreten.
Vom Prinzip der Datenhaltung ist sogar das Gegenteil die saubere Lösung. Vergleichbar mit der Übertragung eines Datums in einer Client-Server-Anwendung: Vom Server kommt das Datum, aber der Client kümmert sich um die richtige Formatierung (MVC - schonmal gehört?). Das ist hier ähnlich: Die zentrale Klasse liefert den richtigen Wert, aber die Klasse, die diese Funktion nutzt, kümmert sich um die richtige Darstellung. Wenn die zentrale Klasse Bestandteil einer öffentlichen Library wäre und Du wärst ihr Autor: Würdest Du dann für jeden Deiner weltweiten Nutzer eigene Formatierungsfunktionen schreiben wollen?
Nee - die Zentralklasse kann zwar Hilfsfunktionen zur Formatierung bereitstellen, aber die eigentliche Formatierung machen die Client-Klassen selbst.
Im konkreten Fall hier bestünde die Möglichkeit, auch die Formatierung von der Zentralklasse erledigen zu lassen, einfach weil wir nicht so eine strenge Datentrennung haben. Ob das - im Hinblick auf die Formatvielfalt - sinnvoll ist, ist wieder eine andere Frage, wo man durchaus unterschiedlicher Meinung sein kann. Aber dass hier Code geschrieben wurde, der "praktisch sofort überarbeitet gehört", muss ich dann doch von mir weisen.

Gruß,
E.

 

[Silas]

Das wollte ich natürlich nicht unterstellen, ich habe deinen Code ja nicht einmal gelesen. Tut mir echt leid, wenn das so rüber kam. Das war eher eine allgemeine Feststellung, die ich deinem

Oh, auch da wüsste ich ein paar Stellen (eine ganz spontan), bei denen man bezüglich Wartbarkeit Ekelpickel bekommt.

anfügen wollte, hatte aber erstmal nichts mit deinen Änderungen zu tun.

Die zentrale Klasse liefert den richtigen Wert, aber die Klasse, die diese Funktion nutzt, kümmert sich um die richtige Darstellung.

Klar, aber jetzt kann man natürlich darüber diskutieren, ob die Maßeinheit Teil des Werts ist oder Teil der Darstellung. Man könnte auch eine eigene Klasse Distance implemtieren, die Methoden wie ToMetersString(), ToKiloMetersString(), ToMilesString(), etc. und noch ein ToString(), das die Standard-Einheiten in Abhängigkeit der Ländereinstellungen ausgibt, bietet. Ein Vorteil der Objektorientierung ist ja nun mal, dass man Daten und den sie verarbeitenden Code in Klassen zusammenfasst. Und Verarbeiten heißt hier in meinen Augen konvertieren (nach String eben) und erstmal nicht Anzeigen. Man kanns aber auch übertreiben, vorallem da Instanziierungen ja -- nicht nur bei ewe und eve -- ein Performance-Engpass sind.

Wenn die zentrale Klasse Bestandteil einer öffentlichen Library wäre und Du wärst ihr Autor: Würdest Du dann für jeden Deiner weltweiten Nutzer eigene Formatierungsfunktionen schreiben wollen?

Natürlich nicht für jeden, aber gängige Formate würde ich unterstützen wollen. Das wären schließlich fachliche Anforderungen meiner Kunden. Hier spielt es _keine_ Rolle, dass die Kunden selbst Entwickler sind, die die Library nutzen und keine Endandwender, die irgend eine GUI bedienen. Wahrscheinlich würde ich nicht für jedes Format eigene Funktionen schreiben, sondern die Nutzer die gewünschten Formatierungen übergeben lassen, wie bei Datums- und Zeitkonvertierungen, in einfachen Fällen (wie hier) würde auch ein Enum reichen.

Aber gerade wenn es sich um eine intern genutzte Bibliothek handelt, hat sich die Variante bewährt, dass man die Library zwar erweiterbar hält, aber erstmal nur die Funktionalitäten implementiert, die man _aktuell_ benötigt. Kommen später weitere Anforderungen hinzu, können und sollen sie von den sie benötigenden Entwicklern ergänzt werden (inkl. vermutlich notwendig werdenden Refactorings natürlich).

Grüße, Silas

 

[Engywuck]

Das war eher eine allgemeine Feststellung, die ich deinem

Oh, auch da wüsste ich ein paar Stellen (eine ganz spontan), bei denen man bezüglich Wartbarkeit Ekelpickel bekommt.

anfügen wollte

Gut, da sind wir dann ja absolut einer Meinung

Aber konkret hier muss man natürlich vorsichtig sein. Die Formatierung kann abhängig sein von 4 Größen: Dem Wert der Zahl, der benötigten Einheit, ob wir metrisch oder imperial denken und der Funktion, für die wir die Zahlenangabe brauchen. All diese Informationen müsste ich meiner zentralen Funktion mitgeben, wenn ich die bisherige Flexibilität behalten will. Das bietet meiner Meinung nach keinen Vorteil.
Anderer Weg: Ich kappe die bisherige Formatvielfalt und einige mich auf einige wenige, dann aber universeller zu brauchernde Formate. Aber auch da muss man sich erst mal einigen - und wie ich den Thread bislang so sehe, wird das schwer

Ich würde vorschlagen, dass die Protagonisten der Zentralisierungstheorie mal die Formatierungsfunktionen bauen, so wie sie sich das vorstellen - ich baue die dann gerne an den entsprechend lokalen Stellen ein.

Gruß,
E.

 

[MiK]

Ich würde vorschlagen, dass die Protagonisten der Zentralisierungstheorie mal die Formatierungsfunktionen bauen, so wie sie sich das vorstellen - ich baue die dann gerne an den entsprechend lokalen Stellen ein.

Das kannich die ganz einfach in einem Satz erklären: Überall, wo eine Entfernung als String ausgegeben werden soll, soll sie das Format wie bisher im GotoPanel haben. (+ je nach Einstellung in imperialistischen Einheiten).

 

[pfeffer]

ich gehöre hier ja auch zu den disktuierern, aber: wir müssen schon aufpassen, dass wir diejenigen, die wirklich was am Code tun, hier nicht mit tollen Ideen und Mäkeleien zu quatschen, so dass sie am Ende
a) wegen der vielen Diskussionen keine Zeit
b) keine Lust mehr haben, am Code zu arbeiten.

Gruß,
Pfeffer.

 

[MiK]

Na gut... dann bin ich halt still...

 

[Engywuck]

Na gut... dann bin ich halt still...

Du könntest ja auch was tun? Die von Dir gewünschten Funktionen so zu implementieren, wie Du Dir das vorstellst, solltest Du ja noch nicht verlernt haben ;-) Und hätte auch weniger Zeit gebraucht, als die, die Du aufgewendet hast, um über dieses immense Thema zu diskutieren...

Gruß,
E.

 

[MiK]

Wenn dich die Meinung der anderen Programmierer nicht interessiert, dann lies hier halt nicht mit. Du hast nach unserer Meinung gefragt und die habe ich dann auch vertreten.

In der Zeit vor dem 1.0 Release habe habe ich über Monate fast jede freie Minute in CW gesteckt. Danach war einfach die Luft raus. Außerdem hat sich auch privat etwas geändert, so dass ich nicht mehr so viel Zeit fürs Programmieren aufbringen kann. Trotzdem versuche ich wenigstens hier im Forum so gut es geht etwas beizutragen. Wenn Dir das nicht gefällt, dann lies es halt nicht. Aber ich muss mir nicht von Dir vorwerfen lassen zu wenig beigetragen zu haben.

 

[greiol]

hey, pssst, hier lesen auch noch andere mit.

 

[Engywuck]

@MiK: Sorry für meinen etwas stichelnden Beitrag, aber der Verve, mit dem Du Dich eingesetzt hast, stand meiner Meinung nach in keinem Verhältnis zum dadurch zu erreichenden Effekt. Daher das etwas schnippische "machs doch selbst, wenn Du unbedingt willst."
Mir ist aber aufgefallen, dass fixe Nachkommastellen doof sind. Was soll ich mit einer Aussage wie "945,216 km" anfangen? Die ",216" können mir ziemlich egal sein. Daher mein Vorschlag: Die nummerischen Angaben zu Entfernung und Geschwindigkeit werden auf 3 signifikante Stellen formatiert. Also Angaben wie:
123 km
23,4 km
4,86 mi.
34,7 m
9,28 ft.
Das sollte doch überall passen und es wäre einheitlich programmierbar ohne viele IFs.

Gruß,
E.

 

[Silas]

Aber konkret hier muss man natürlich vorsichtig sein. Die Formatierung kann abhängig sein von 4 Größen: Dem Wert der Zahl, der benötigten Einheit, ob wir metrisch oder imperial denken und der Funktion, für die wir die Zahlenangabe brauchen. All diese Informationen müsste ich meiner zentralen Funktion mitgeben, wenn ich die bisherige Flexibilität behalten will. Das bietet meiner Meinung nach keinen Vorteil.

Meiner Meinung nach muss das ja gar nicht unbedingt eine Funktion sein. Können ja ruhig mehrere bleiben, die aber in einer gemeinsamen Klasse (z.B. CacheWolf.navi.Metrics) angesiedelt sein sollten. Single responsibility und so Hier ergeben sich dann sicher auch wieder Möglichkeiten zum Rausziehen von Schnittmengen der verschiedenen Funktionen in private Methoden. Man könnte z.B. CacheHolder.getDistance(), das Setzen von strSpeed in GotoPanel.drawGPSData() [hier steht übrigens noch "km/k" als Einheit in Line 601] dahin auslagern, verallgemeinern und zum Schluss -- wo möglich -- zusammenfassen.

Anderer Weg: Ich kappe die bisherige Formatvielfalt und einige mich auf einige wenige, dann aber universeller zu brauchernde Formate. Aber auch da muss man sich erst mal einigen - und wie ich den Thread bislang so sehe, wird das schwer
[...]

Klingt find ich auch sinnvoll, die drei signifikanten Stellen sind ja schon mal ein guter Vorschlag.

Ganz allgemein würde ich euch echt liebend gerne bei der Cachewolf-Weiterentwicklung unterstützen, aber ich fürchte mir fehlt schon die Zeit für die Einarbeitung. Diese Woche war ich drei Tage krank und meine bessere Hälfte ist im Urlaub, daher konnte ich wenigstens mal bissl im Forum und den Sourcen vorbeischauen, aber generell siehts echt düster aus. Als User bin ich aber total begeistert von der Software und als Entwickler schreckt mich an den Quelltexten auch nichts ab, daher bedauere ich das wirklich.

Grüße, Silas

 

[MiK]

Immer 3 signifikante Stellen halte ich für zu starr. Bei der kleinsten Einheit sind Nachkommastellen im Rahmen der Messungenauigkeiten nicht sinnvoll. Bei sehr großen Distanzen würde ich zwar die Nackommastellen streichen, aber sonst nicht weiter runden. Das würde doch stark verwirren. Außer Du möchtest das dann in Exponentialschreibweise ausgeben.

 

[Engywuck]

Bei großen Zahlen gebe ich Dir Recht: Ab 100 die Nachkommastellen wegformatieren sollte reichen.
Bei den kleinen Einheiten ist ein "3,47 m" Abstand zwar nicht so richtig sinnvoll, hat dafür aber den Charme, dass ich die Zahl formatieren kann, ohne auf die Einheit gucken zu müssen. Sonst ist da wieder ein IF mehr drin. Mit der Tatsache, dass die Aussage "3,47 m" mit der Realität nichts zu tun hat, kann ich mich abfinden. Ich weiß aber nicht, ob die Nachkommastellen bei der Anwendung stören würden (ich navigiere immer mit meinem GPS). Sobald es stört, sollte man sie natürlich entfernen.

Gruß,
E.

 

[MiK]

Beim Navigieren sind das dann nur sinnlos herumflackernde Ziffern. Vielleicht sollten wir es einfach so lassen, wie es jetzt ist.