phpbar.de logo

Mailinglisten-Archive

[php] Typkonversion vielleicht doch besser? (Ex: Re: [php] oohforms - add_element - $cv_tab) add_element - $cv_tab)

[php] Typkonversion vielleicht doch besser? (Ex: Re: [php] oohforms - add_element - $cv_tab) add_element - $cv_tab)

Oliver Kummerow naklar_(at)_altavista.net
Thu, 20 Jan 2000 18:28:51 +0100


Hallo Ulf,


sag mal, ich hoffe ja nur, dass nicht eines Tages eine Riesenrechnung
für extended Teach-Ins von Dir kommt. 

Hier eine kleine Ergänzung - Der Gesundheitsxy warnt vor dem Gebrauch
untypisierter Variablen:

> PHP hat weder streng getypte Variablen noch verlangt es nach einem
> strengen Verfahren von Definition und Initialisierung, wenn eine neue
> Variable benötigt wird.

IMHO ist ungetypt Zeug sehr häufig für den Ofen, weil es im Ernstfall
nicht richtig funktioniert oder - eventuell sogar unerkannte - Fehler
produziert. Das hält beim Programmieren genauso auf wie die eigene
Blödheit, die zugegebenermaßen das Hauptproblem ist...

Die Entwickler von PHP konnten sich anscheinend nicht recht entscheiden,
welches der richtige Weg sei, ansonsten würde es
Typkonvertierungsfunktionen wie (string),(int) nicht geben. Der Doktrin
der automatischen Konversion folgend, wären sie schlichtweg überflüssig. 


Ein paar Demos, wie man recht schön in die Pfütze fallen kann:

1. 
$j = "1";
echo "foo_$j";
Ergebnis:  foo_1
Wunderbare Stringverknüpfung mit Variablen innerhalb von
Zeichenkettendelimitern. Irgendwie seltsam. Aber funktioniert
(irritierenderweise).


2. Jetzt mit Arrays

$j=1;
$daten [$j+1]="foo";
echo $daten [2];
Ergebnis:  foo

ok, noch kein Problem. 


3. Der Geneigte wird jetzt auf die automatische Typkonversion vertrauen.
Und fällt...

$j = 1;
$daten [$j+1."bar"]="foo";
echo $daten ["2bar"];
Ergebnis:  Parse error: parse error in testcode.php on line ..

... prompt auf die Nase. Warum? Weil der String-Concatenator "." zu
dicht an der 1 steht. Ansonsten ginge es. Ohne automatische
Typkonversion hätte man von vorneherein sauberen Code erzeugt, ungefähr
so:

$j = 1;
$daten [(string)($j+1)."bar"]="foo";
echo $daten ["2bar"];
Ergebnis:  foo




4. Jetzt versuch' mal das - einfach die Zuweisungen umgestellt:

$j = "1";
$daten ["bar" . $j+1]="foo";
echo $daten ["2bar"];
Erg.:  Warning: Uninitialized variable or array index or property (2bar)
in testcode.php on line ..

Vorbei. Nicht zu gebrauchen. Dass das nicht unbedingt nur mit Arrays zu
tun hat, siehst Du im folgenden, es gibt noch merkwürdigere Reaktionen:


5.
echo "foo" . 1;
Ergebnis:  foo1
ja

echo "foo" . 1*2;
Ergebnis:  foo2
ja

Hier der besondere Spaß:
echo "foo" . 1+2;
Ergebnis:  2

???? Wie bitte? Wo kommt denn das plötzlich her ????


echo "foo" . (1+2);
Ergebnis:  foo3
Geschafft... nur, ob man da immer dran denkt? Sieht aus wie eine Falle
der besonderen Art.



Deswegen:

> +++ Warum Typen? +++
> Streng typisierte Variablen haben auch Vorteile. 

Sicher. Und der wichtigste ist, dass solche Fehler, die in der
zwangsläufig mangelhaften Konzeption eines überforderten Parsers
begründet sind, nicht auftreten werden. Vielleicht sollte man
grundsätzlich die Typkonversionsfunktionen einsetzen, um derartige
Reinfälle zu vermeiden. Dann könnte man sie aber gleich grundsätzlich
einführen (oder zumindest per Option in der Ini erzwingen lassen) und
damit auch auf Appetithappen wie === verzichten.



mit freundlichen Grüßen, 
oK.


php::bar PHP Wiki   -   Listenarchive