[PHP5] Overloading, Exceptions... Meine Erfahrungen...

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/php5_overloading_exceptions_meine_erfahrungen_126476/page_1 - zur Vollversion wechseln!

watchout schrieb am 06.10.2004 um 19:29

Ich hab jetzt seit ein paar Tagen versucht das neue Objektmodell von PHP5 sinnvoll zu nutzen, einige Teile sind praktisch - andere wären es, würden sie auf die Weise funktionieren wie man es erwarten würde...

ad Overloading
"__call" überladet nicht wie man erwarten würde _alle_ funktionen, sondern "emuliert" lediglich von aussen eine funktion, die nicht definiert wurde. somit ist vielleicht ein verwendungszweck davon fehlermenldungen zu vermeiden - aber bestimmt nicht das überladen von anderen Funktionen, wie die Bezeichnung einen verleitet zu glauben.

Doch nicht nur dass, ich hätte zumindest erwartet, dass "call" "private" bzw. "protected" methods überladet, was ebenfalls nicht der fall ist. Demnach ist die Nutzbarkeit dieser Funktion extrem eingeschränkt, sie sollte eher "__default" heissen :rolleyes:

Das ist natürlich eindeutig ein Fehler in der Dokumentation, aber hier ein Beispiel zur Untermauerung :

Code: PHP

class myClass
{
	function __call($szFuncName,$aArguments)
	{
		echo 'myClass::__call, Function called: "'.$szFuncName.'"<br />';
	}
	function foo()
	{
		echo 'myClass::foo<br />';
	}
	Private function bar()
	{
		echo 'myClass::bar<br />';
	}
}
$myClass = new myClass();
$myClass->foo();  # Calls foo()
$myClass->none(); # Calls __call()
$myClass->bar();  # Causes Fatal Error

Output:
myClass::foo
myClass::__call, Function called: "none"

Fatal error: Call to private method myClass::bar() from context '' in [...]\tests\php5_classes_call.php on line 22

ad Exceptions
Gleich meine erste try-catch struktur hat php dermassen gekillt, dass nichtmal eine Fehlerausgabe möglich war - den Grund zu finden war nicht leicht, wenn man nämlich programmtechnisch keinen Fehler gemacht hat. Und wenn einen ausserdem oben genanntes (nicht vorhandenes) Overloading einen Strich durch die Rechnung macht... Der Grund war jedenfalls, dass die Funktion "call_user_func_array" scheinbar einen Fehler hat.
Dieser Fehler verhindert scheinbar nicht nur dass die Exception catched wird, sondern in verbindung mit einer catch-struktur auch dass php selbst diesen error catched, wodurch die ausführung abgebrochen wird...

vielleicht kommt noch was dazu, aber fürs erste hab ich mal genug geschrieben

/watchout

Rektal schrieb am 06.10.2004 um 23:23

Servas

Kannst du ein konkretes Beispiel fuer call_user_func_array zusammenbasteln?

Mit __call usw. hab' ich mich nicht beschaeftigt.
Ich verwende die Neuerungen (interfaces, abstract) zur Definierung meiner Schnittstellen fuer die Applikation, Exceptions verwende ich oft, angefangen von einer eigenen exception-klasse von der alle anderen abgeleitet sind usw., hilft sehr leicht fehler zu behandeln (auch wenns nicht immer sprichwoertliche "exceptions" sind). Haupt-Hobby nebenbei ist, alle core-PHP-funktionen die ich aufrufe und die schiefgehen koennen (copy, imagecreate, etc, etc) ueber einen Wrapper aufzurufen, der im Fehlerfall exceptions wirft. Das hilft wahnsinnig z.b. bei Eingabe von komplexeren Formularen (mehrere uploads, dann geht dort was schief, rollback bei der datenbank, formular wieder zurueck zum user usw.).

Problem das ich habe mit der neuen "Macht": macht faengt frueher und leichter an, Dinge zu abstrahieren und verfilzt sich dann in zu grossen Klassen-hierarchien, versucht irgendwelche OO-Pattern anzubringen, was schon mal in die Hose gehen kann. Hier sind eindeutig die staerken im Design gefragt, genauso wie im coden.

watchout schrieb am 06.10.2004 um 23:49

hab atm keine zeit/lust jetzt noch weiter in diese Richtung zu testen, da ich auch derzeit im "OO-Fieber" bin, und trotz exception, traces usw. bis jetzt nicht herausfinden konnte wo ein einzelnes zeichen (ein "<") in meine variable reinkommt