<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare zu: Funktionen aufrufen, nur falls sie auch existieren</title>
	<atom:link href="http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/</link>
	<description>PhpHatesMe, but that&#039;s ok!</description>
	<lastBuildDate>Mon, 06 Feb 2012 20:59:49 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Von: maz</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41580</link>
		<dc:creator>maz</dc:creator>
		<pubDate>Sat, 27 Feb 2010 16:49:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41580</guid>
		<description>Hallo, ich muss KingCrunch Recht geben. In PHP kann man viel anstellen, aber nicht alles ist sinnvoll. Ich finde, was man auf eine Weise in PHP aber nicht auch in anderen Sprachen umsetzen kann, sollte man sich zweimal überlegen. Z.B. ist Late Static Binding zwar auf den ersten Blick recht nützlich, aber jeder weiß, dass man für Vererbung/Polymorphie normalerweise ein Objekt benötigt (C++ Entwickler errinnern sich vielleicht an die vtable).
Durch das richtige Designmuster wird man nie auf Late Static Binduing angewiesen sein. Hinzu kommt, dass ich kein Fan von &quot;Global State&quot; bin und somit statische Dinge sowieso vermeide. (Kann hier nur empfehlen: http://www.youtube.com/watch?v=-FRm3VPhseI)
Um zum Beitrag noch was loszuwerden: Wieso setzt man kein Eventsystem a la Observer ein? Ein Plugin-System auf Funktionsbasis ist meiner Meinung nach keine gute Wahl, denn wie können sich hier mehrere Plugins für eine Aufgabe registrieren?</description>
		<content:encoded><![CDATA[<p>Hallo, ich muss KingCrunch Recht geben. In PHP kann man viel anstellen, aber nicht alles ist sinnvoll. Ich finde, was man auf eine Weise in PHP aber nicht auch in anderen Sprachen umsetzen kann, sollte man sich zweimal überlegen. Z.B. ist Late Static Binding zwar auf den ersten Blick recht nützlich, aber jeder weiß, dass man für Vererbung/Polymorphie normalerweise ein Objekt benötigt (C++ Entwickler errinnern sich vielleicht an die vtable).<br />
Durch das richtige Designmuster wird man nie auf Late Static Binduing angewiesen sein. Hinzu kommt, dass ich kein Fan von &#8220;Global State&#8221; bin und somit statische Dinge sowieso vermeide. (Kann hier nur empfehlen: <a href="http://www.youtube.com/watch?v=-FRm3VPhseI" rel="nofollow">http://www.youtube.com/watch?v=-FRm3VPhseI</a>)<br />
Um zum Beitrag noch was loszuwerden: Wieso setzt man kein Eventsystem a la Observer ein? Ein Plugin-System auf Funktionsbasis ist meiner Meinung nach keine gute Wahl, denn wie können sich hier mehrere Plugins für eine Aufgabe registrieren?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Julian</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41535</link>
		<dc:creator>Julian</dc:creator>
		<pubDate>Thu, 25 Feb 2010 23:35:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41535</guid>
		<description>Von Objektorientierung ist in dem Zusammenhang selbstverständlich nicht zu reden. OOP befasst sich mit Objekten (also Instanzen von Klassen) und weniger mit derlei statischen Konstrukten. Das ist oft eine Hintertür in meinen Augen.
Genau wie einige andere, würde ich in diesem Zusammenhang Fehlerbehandlung kritisieren - die ist nämlich nicht mehr gegeben. In welchem Zusammenhang darf man das Konstrukt verwenden? Nur mit Aufrufen von Plugin-Funktionen? Was ist, wenn ich es mit anderen Funktionen in Verbindung bringe .. schon entstehen Fehler.
Ich habe vor nicht all zu langer Zeit meinen Professor gefragt, wieso es (in Java) möglich ist, dass eine Instanz einer Klasse auf ein privates Attribut einer anderen Instanz derselben Klasse direkt zugreifen kann, wo man doch ohne direkten Zugriff und über Getter-Methoden eine viel bessere Kapselung erzwingen könnte. Die Antwort war in diesem Zusammenhang: &quot;Programmcode soll sich nicht vor sich selbst schützen / kapseln, sondern vor äußeren Systemen&quot; (sinngemäß). Damit möchte ich sagen, dass es nicht Sinn und Zweck ist, in einer Anwendung jede mögliche Fehlerquelle, die durch Fremdentwickler entsteht, auf Herz und Nieren zu prüfen. Plugins müssen nunmal korrekt entwickelt werden - es darf vor der Installation des Plugin durchaus eine Überprüfung stattfinden, aber eine vollständige Kapselung ist schier unmöglich, so dass immer Fehler auftreten können. Es ist also Aufgabe der Entwickler der Plugins, dieselben so zu entwickeln, dass sie den selben Standards wie die Anwendung selbst entsprechen.
Man muss hier eben ein Mittelmaß finden und meines Erachtens geht es schon zu weit, jede Funktion eines Plugins auf Existenz zu prüfen, denn man sollte davon ausgehen können, dass, wenn ein Plugin installiert wurde, entsprechende Funktionen zur Verfügung stehen. Dann muss man eben nur korrekte Abhängigkeiten beachten.
Übrigens weiß die Kern-Anwendung gar nicht von möglichen Funktionen, die ein Plugin zur Verfügung stellt. Nur Plugins können voneinander abhängen und optionale Funktionen aufrufen. Die Kern-Anwendung dagegen sollte ohne Plugins auskommen. Demnach ist es - unter Vorraussetzung, dass ein korrekt eingebundenes Plugin die Funktionen bereitstellt - eine Frage der Abhängigkeit von Plugins, ob ein Plugin eine bestimmte Funktion eines Anderen aufrufen kann. Kern-Funktionen sollten ja vorhanden bleiben.</description>
		<content:encoded><![CDATA[<p>Von Objektorientierung ist in dem Zusammenhang selbstverständlich nicht zu reden. OOP befasst sich mit Objekten (also Instanzen von Klassen) und weniger mit derlei statischen Konstrukten. Das ist oft eine Hintertür in meinen Augen.<br />
Genau wie einige andere, würde ich in diesem Zusammenhang Fehlerbehandlung kritisieren &#8211; die ist nämlich nicht mehr gegeben. In welchem Zusammenhang darf man das Konstrukt verwenden? Nur mit Aufrufen von Plugin-Funktionen? Was ist, wenn ich es mit anderen Funktionen in Verbindung bringe .. schon entstehen Fehler.<br />
Ich habe vor nicht all zu langer Zeit meinen Professor gefragt, wieso es (in Java) möglich ist, dass eine Instanz einer Klasse auf ein privates Attribut einer anderen Instanz derselben Klasse direkt zugreifen kann, wo man doch ohne direkten Zugriff und über Getter-Methoden eine viel bessere Kapselung erzwingen könnte. Die Antwort war in diesem Zusammenhang: &#8220;Programmcode soll sich nicht vor sich selbst schützen / kapseln, sondern vor äußeren Systemen&#8221; (sinngemäß). Damit möchte ich sagen, dass es nicht Sinn und Zweck ist, in einer Anwendung jede mögliche Fehlerquelle, die durch Fremdentwickler entsteht, auf Herz und Nieren zu prüfen. Plugins müssen nunmal korrekt entwickelt werden &#8211; es darf vor der Installation des Plugin durchaus eine Überprüfung stattfinden, aber eine vollständige Kapselung ist schier unmöglich, so dass immer Fehler auftreten können. Es ist also Aufgabe der Entwickler der Plugins, dieselben so zu entwickeln, dass sie den selben Standards wie die Anwendung selbst entsprechen.<br />
Man muss hier eben ein Mittelmaß finden und meines Erachtens geht es schon zu weit, jede Funktion eines Plugins auf Existenz zu prüfen, denn man sollte davon ausgehen können, dass, wenn ein Plugin installiert wurde, entsprechende Funktionen zur Verfügung stehen. Dann muss man eben nur korrekte Abhängigkeiten beachten.<br />
Übrigens weiß die Kern-Anwendung gar nicht von möglichen Funktionen, die ein Plugin zur Verfügung stellt. Nur Plugins können voneinander abhängen und optionale Funktionen aufrufen. Die Kern-Anwendung dagegen sollte ohne Plugins auskommen. Demnach ist es &#8211; unter Vorraussetzung, dass ein korrekt eingebundenes Plugin die Funktionen bereitstellt &#8211; eine Frage der Abhängigkeit von Plugins, ob ein Plugin eine bestimmte Funktion eines Anderen aufrufen kann. Kern-Funktionen sollten ja vorhanden bleiben.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: KingCrunch</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41530</link>
		<dc:creator>KingCrunch</dc:creator>
		<pubDate>Thu, 25 Feb 2010 15:09:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41530</guid>
		<description>Andi:
1. Wenn eine Funktion nur optional aufgerufen werden soll, wäre ihr Fehlen kein Fehler.
2. Siehe 1 ;) zB Widgets: Wenns fehlt, fehlts, aber gefährlich isses nicht</description>
		<content:encoded><![CDATA[<p>Andi:<br />
1. Wenn eine Funktion nur optional aufgerufen werden soll, wäre ihr Fehlen kein Fehler.<br />
2. Siehe 1 <img src='http://www.phphatesme.com/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />  zB Widgets: Wenns fehlt, fehlts, aber gefährlich isses nicht</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Andi</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41507</link>
		<dc:creator>Andi</dc:creator>
		<pubDate>Thu, 25 Feb 2010 08:08:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41507</guid>
		<description>Hm...also nachdem ich mir die ganze Diskussion durchgelesen habe, erschließt sich für mich immer noch nicht der Nutzen dieser eigentlich interessanten Idee.

Fazit bleibt für mich:
1. Fehlermeldungen haben Ihre Daseinsberechtigung und sind beim Debuggen unverzichtbar (siehe Julians Kommentar).
2. Die Funktion soll etwas tun (siehe Christopher K.)! Ich unterdrücke einen Fehler und meine Daten sind dazu noch unbrauchbar.
3. Gerade bei einem Plugin kann bei der Installation auf die Systemvoraussetzungen überprüft werden (metalguys Kommentar). -&gt; http://php.net/manual/function.version-compare.php</description>
		<content:encoded><![CDATA[<p>Hm&#8230;also nachdem ich mir die ganze Diskussion durchgelesen habe, erschließt sich für mich immer noch nicht der Nutzen dieser eigentlich interessanten Idee.</p>
<p>Fazit bleibt für mich:<br />
1. Fehlermeldungen haben Ihre Daseinsberechtigung und sind beim Debuggen unverzichtbar (siehe Julians Kommentar).<br />
2. Die Funktion soll etwas tun (siehe Christopher K.)! Ich unterdrücke einen Fehler und meine Daten sind dazu noch unbrauchbar.<br />
3. Gerade bei einem Plugin kann bei der Installation auf die Systemvoraussetzungen überprüft werden (metalguys Kommentar). -&gt; <a href="http://php.net/manual/function.version-compare.php" rel="nofollow">http://php.net/manual/function.version-compare.php</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Simon</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41495</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Wed, 24 Feb 2010 22:00:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41495</guid>
		<description>Das ist für mich kein OOP, das ist Vergewaltigung von Klassen.
Auch wenns nett aussieht, sauber ist das nicht :-)</description>
		<content:encoded><![CDATA[<p>Das ist für mich kein OOP, das ist Vergewaltigung von Klassen.<br />
Auch wenns nett aussieht, sauber ist das nicht <img src='http://www.phphatesme.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: DSB</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41494</link>
		<dc:creator>DSB</dc:creator>
		<pubDate>Wed, 24 Feb 2010 21:25:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41494</guid>
		<description>Im genannten Kontext geht es ja darum PlugIns anzusteuern. Wenn diese nicht erreichbar sind, sollte das die Core-Funktionalität des Hauptskripts nicht beeinflussen, so dass die Vorgehensweise in Ordnung sein sollte.

Sicherlich könnte man jetzt einen Fall konstruieren, wo ein PlugIn von einem anderen abhängig ist, das übergeordnete nicht verfügbar ist und es dadurch im abhängigen PlugIn knallt. Aber dann sollte das abhängige PlugIn ebenfalls Prüfmethoden für das Vorhandensein des Haupt-PlugIns besitzen, welche dann greifen und es deaktivieren sollten. 
Insofern betrachte ich die Vorgehensweise der Prüfung mit function_exists als legitime und schnelle Möglichkeit. 
Just my 2 Cents.</description>
		<content:encoded><![CDATA[<p>Im genannten Kontext geht es ja darum PlugIns anzusteuern. Wenn diese nicht erreichbar sind, sollte das die Core-Funktionalität des Hauptskripts nicht beeinflussen, so dass die Vorgehensweise in Ordnung sein sollte.</p>
<p>Sicherlich könnte man jetzt einen Fall konstruieren, wo ein PlugIn von einem anderen abhängig ist, das übergeordnete nicht verfügbar ist und es dadurch im abhängigen PlugIn knallt. Aber dann sollte das abhängige PlugIn ebenfalls Prüfmethoden für das Vorhandensein des Haupt-PlugIns besitzen, welche dann greifen und es deaktivieren sollten.<br />
Insofern betrachte ich die Vorgehensweise der Prüfung mit function_exists als legitime und schnelle Möglichkeit.<br />
Just my 2 Cents.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Christopher K.</title>
		<link>http://www.phphatesme.com/blog/php/funktionen-aufrufen-nur-falls-sie-auch-existieren/comment-page-1/#comment-41493</link>
		<dc:creator>Christopher K.</dc:creator>
		<pubDate>Wed, 24 Feb 2010 21:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=5320#comment-41493</guid>
		<description>Was mir dabei aufgefallen ist:

Ich rufe eine Funktion ja meist nicht auf, weil es ganz nett wäre, sie aufzurufen, sondern weil ich sie brauche. Das heißt, wenn es sie nicht gibt, muss ich etwas tun. Sei es einen Fehler ausspucken, eine Exception werfen oder eine andere Funktion verwenden. Und das berücksichtigt diese Lösung hier nicht. Wenn ich mache if(function_exists()) kann ich per else irgendwas anderes tun.
Einfach im Code weiter zu gehen kann fatale Folgen haben, weil ich ja i.d.R. davon ausgehe, dass die Funktion etwas tut.

Was das Cachen angeht: Verlockende Idee, so ein Universalcache. Aber wie lange ist der Cache gültig? Was, wenn die Funktion außer einer Rückgabeberechnung noch etwas anderes tut, wie eine Datei schreiben? Was, wenn die Funktion etwas zeitabhängiges tut? Das muss man immer individuell machen mit dem Cachen, ein individueller Cache nutzt nur für einfache Fälle was.</description>
		<content:encoded><![CDATA[<p>Was mir dabei aufgefallen ist:</p>
<p>Ich rufe eine Funktion ja meist nicht auf, weil es ganz nett wäre, sie aufzurufen, sondern weil ich sie brauche. Das heißt, wenn es sie nicht gibt, muss ich etwas tun. Sei es einen Fehler ausspucken, eine Exception werfen oder eine andere Funktion verwenden. Und das berücksichtigt diese Lösung hier nicht. Wenn ich mache if(function_exists()) kann ich per else irgendwas anderes tun.<br />
Einfach im Code weiter zu gehen kann fatale Folgen haben, weil ich ja i.d.R. davon ausgehe, dass die Funktion etwas tut.</p>
<p>Was das Cachen angeht: Verlockende Idee, so ein Universalcache. Aber wie lange ist der Cache gültig? Was, wenn die Funktion außer einer Rückgabeberechnung noch etwas anderes tut, wie eine Datei schreiben? Was, wenn die Funktion etwas zeitabhängiges tut? Das muss man immer individuell machen mit dem Cachen, ein individueller Cache nutzt nur für einfache Fälle was.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

