Hallo Karsten,
Post by Karsten SosnaVorab, ich bin sicherlich kein Verfechter typengerechter
Arbeitsweise!
Das "kein" im vorstehenden Satz sollte vermutlich ein
"ein" sein?
Post by Karsten SosnaIch würde auch sehr gerne immer den passenden Typ
an eine Routine übergeben wollen in
Ich sehe keinen Grund, das nicht zu tun.
Wird ein numerischer Datentyp erwartet, übergebe
ich einen solchen und wird ein String erwartet, dann
eben einen String.
Post by Karsten Sosnader Erwartung, das dieses auch berücksichtig wird.
Von wem wird was nicht berücksichtigt.
Post by Karsten SosnaLeider ist das aber nicht möglich oder wird ignoriert.
Warum ist was nicht möglich und von wem wird was
ignoriert?
Wenn ich eine Anwendung konzipiere, erstelle ich erst
mal ein durchdachtes Objektmodell und weiss dann
welche Eigenschaften dieser Objekte welche Daten-
typen erwarten bzw. welche Datentypen welche
Funktionen dieser Objekte liefern. Die Wahl der
Datentypen bei der Erstellung des/der Objektmodell/e
erfolgt passend zur gestellten Aufgabe. Ich sehe nicht,
was dabei nicht möglich sei oder von irgendjemandem
ignoriert würde.
Post by Karsten SosnaEinfache sind alleine im Graphics-Objekt wieder zu finden.
Fast alle Überladungen zum Zeichnen können auch mit
Single-Werten aufgerufen werden, wobei sich jeder vorstellen
könnte das wohl kaum 0.57 Pixel gezeichnet werden können.
Ein Single muss ja nicht zwangsläufig eine gebrochene
Zahl darstellen.
Post by Karsten SosnaGleiches gilt für Anwendungen die Parameter entgegennehmen
(auch wenn sie Typ String sind) und dann etwas tun, was
ich ich nicht einsehen kann.
Schnittstellen zu Fremdprogrammen sind möglicherweise
nicht so umfassend dokumentiert, dass man den
Grund für den gewählten Datentyp nicht sofort erkennt.
Wobei ich nicht ausschliessen will, dass es eine
Menge Anwendungen gibt, die eben schlecht konzipiert
sind und tatsächlich mit eher untauglichen Datentypen
arbeiten. Typisches Beispiel war das Jahr-2000-Problem
in vielen Anwendungen, das nur deshalb entstand, weil
man Datumswerte als Strings gespeichert und verarbeitet
hatte.
Post by Karsten SosnaVISIO ist solch eine Anwendung alles was über 5
Dezimalstellen hinausgeht wird auf 4 Stellen gerundet.
Ich kenne Visio zu wenig um darüber fundiert diskutieren
zu können. Aber das ändert nichts daran, dass ich in
eigenen Anwendungen darauf achte, konsequent typgerecht
zu arbeiten, und eben beim Erstellen der Objektmodelle
schon genau überlege, welcher Datentyp für welchen
Zweck der jeweils "zweckmässige" ist.
Post by Karsten SosnaSingle als Übergabeparameter würde also vollends
ausreichen, VISIO erwartet aber einen String und den
nach allen Regel der Kunst in der amerikanischen
Schreibweise(ohne Tausendertrennen und nicht in
Exponentialschreibweise). Wenn dem immer so ist
kann man dementsprechend arbeiten.
Natürlich werden sehr häufig Zahlendarstellungen in
Strings verpackt, wie z.B. bei XML und vielen anderen
Protokollen zum Datenaustausch, die textbasiert
arbeiten, das ist aber doch noch lange kein Grund
im eigenen Programmcode mit unpassenden Datentypen
zu arbeiten. Es gibt letztlich nur zwei Schnittstellen,
an denen von numerischen Datentypen zu Strings und
evtl. umgekehrt gewandelt werden muss. Das ist zum
einen die Schnittstelle Maschine - Mensch, der Mensch
gibt Zahlen in der im geläufigen länderspezifischen
Schreibweise über eine Tastatur ein, oder er liest sie
am Bildschirm oder auf Papier oder sonstigem
Medium ebenfalls wieder in der von ihm gewohnten
länderspezifischen Schreibweise. Die andere
Schnittstelle wäre dann eine zum Datenaustausch
mit anderen Maschinen (Maschine - Maschine).
Hier wird häufig, aus welchen Gründen auch immer,
textbasiert gearbeitet und man verwendet hierbei
gerne die invariante (englische) Formatierungsweise
für Zahlendarstellungen.
Ich sehe keinen vernünftigen Grund, beim Übergang
an der Schnittstelle Maschine - Mensch eine Umwandlung
von länderstpezifischem String in den jeweils aufgaben-
gerechten Datentyp bzw. umgekehrt vorzunehmen und
ebenso an der Schnittstelle Maschine - Maschine eben
von Strings mit invarianter (engl.) zum aufgabengerechten
Datentyp und umgekehrt zu wandeln.
Post by Karsten SosnaIch habe es ablegt, ständig Usereingaben so zu verändert
das es wieder passt.
Ich entwickle fast ausschliesslich für international
arbeitende Industrieunternehmen und da wird mir sowas
ganz selbstverständlich ins Pflichtenheft geschrieben.
Ich finde das auch ganz vernünftig und sehe darin nicht
das geringste Problem. Alle von mir genutzten
Programmiersprachen bieten einfachste Möglichkeiten,
Zahlendarstellungen beliebiger Formatierung in den
jeweils aufgabengerechten Datentyp und umgekehrt
num. Datentypen in entspr. formatierte Strings umzuwandeln.
Post by Karsten SosnaMich interessiert das nicht mehr ob jeder eine Punkt
oder ein Komma als Dezimaltrenner ansieht.
Na ja, wenn Dir ein Auftraggeber bestimmte Vorgaben
ins Pflichtenheft schreibt, solltest Du diese Vorgaben
tunlichst erfüllen, wenn Du hinterher nicht mächtigen
Ärger haben willst und in Folge dessen vermutlich
auch bald einen Kunden weniger.
Selbst ohne Vorgabe im Pflichtenheft ist es für mich
eine Selbstverständlichkeit, dem Benutzer einer
Anwendung die Möglichkeit zu geben, Zahlen in der
von ihm gewohnten länderspezifischen Schreibweise
eingeben bzw. lesen zu können. Der Programmier-
aufwand hierfür ist minimal und verbessert den Komfort
und die Sicherheit einer Anwendung ganz erheblich, ist
also ein nicht unwichtiges Qualitätsmerkmal.
Post by Karsten SosnaWenn ich eine Zahl erwarte(als String) dann ist
der Dezimaltrenner ein Punkt und es gibt keine
Tausendertrenner.
s.oben:
Pflichtenheft und Qualitätsmerkmale.
Oder wie man in Bayern sagt, "wer zahlt schafft an".
Post by Karsten SosnaJegliche Eingaben die nicht den Anforderungen
entsprechen führen grundsätzlich zu einem Abbruch.
Ein Programm, welches bei Fehleingaben einfach
abbricht, wird Dir vermutlich kein zahlender Kunde
abnehmen.
Post by Karsten SosnaDiskussionsspielraum gibt es nicht mehr.
Den gibt es insofern nicht, als ein Pflichtenheft oder
eben ganz einfach allgmeine Qualitätsansprüche
definieren, wie eine Anwendung zu arbeiten hat.
Post by Karsten SosnaUnd wenn ich erwarte das eine Zahl im Stringformat
zu üdergeben ist bestimmte Regeln zu befolgen hat,
so ist das so.
Sorry, aber das ist schon recht blauäugig.
Der Auftraggeber oder eben ganz allgemein der
Kunde bestimmt, was eine Anwendung zu können
hat und wie sie zu arbeiten hat. Mit "ich mache das
so und nicht anders" würdest Du sehr schnell ohne
Kunden dastehen.
Post by Karsten SosnaIch habe bestimmt über 50 Terminalanwendungen
geschrieben. All diese Anwendungen haben feste
Übergabeparameter die eingehalten werden müssen.
Es spricht doch auch gar nichts dagegen, wenn
von einem Rechner zu einem nicht intelligenten
Terminal Daten textbasiert, mit einem bestimmten
vordefinierten Format übertragen werden, das muss
aber doch nicht dazu führen, dass man dem Anwender
zumutet, mit ihm ungewohnten Formatierungen bei
der Eingabe von Daten und beim Lesen von Daten
zu arbeiten oder auf der Rechnerseite mit unpassenden
Datentypen zu arbeiten.
Post by Karsten SosnaDies ist zwingend notwendig damit ich sie ggf.
1:1 an andere Schnittstellen weitergeben muss.
Wenn eine bestimmte Schnittstellenvereinbarung
für den Datenaustausch zwischen zwei Rechnern
oder sonstigen Endgeräten vereinbart ist, dann muss
man sich natürlich daran halten, aber auch das muss
nicht dazu führen, dass man den Anwender bei der
Dateneingabe und beim Lesen von Daten mit ungewohnten
Formatierungen traktiert und/oder Anwendungsintern
mit Strings arbeitet, wenn man eigentlich Zahlen, sprich
numerische Datentypen zu verarbeiten hat.
Post by Karsten SosnaIch habe keinen Bedarf dann auch auf die Kultur zu achten,
Mein Auftraggeber haben diesen Bedarf ausnahmslos
und ich hatte bisher kein Problem diese Forderung zu
erfüllen.
Post by Karsten Sosnazumal das gar nicht möglich ist.
Was ist konkret nicht möglich?
Post by Karsten SosnaDer Punkt ist ein Dezimaltrenner,
Nein, der Punkt ist ein Schriftzeichen wie jedes
andere auch, und ob er als Dezimaltrenner, als Satztrenner
oder was auch immer verwendet wird, ist eine rein
willkürliche Vereinbarung.
Post by Karsten Sosnadas Komma ein Seperator,
Was für den Punkt gilt, gilt ebenso für das Komma.
Post by Karsten Sosnainsofern bleibt hier kein Spielraum mehr.
Diese Verfahren fahre ich seit 1998 und habe
keine Probleme damit.
Nun, meine Erfahrungen mit international arbeitenden
Industrieunternehmen habe ich Dir ja bereits geschildert
und wie ich über Qualitätsstandards denke, dürfte
auch sichtbar geworden sein.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)