PHP-Extensions /und/ jetzt geht "format" nicht mehr :(

[WauWau]

Hallo Christian,

http://de.php.net/manual/de/function.dl.php.
Ich kenne dl(). Aber auch hier wird nur dynamisch gebunden.

Und was macht "use" dann? Ach ja, ich glaube ich vergaß, dass diese PHP-Extensions ja kompilierte ".so" oder (windows) ".dll"-"Programmchen" sind, im Gegensatz zu den Perl-Packages. Oder verwechsel ich hier wieder etwas?

Namespaces gibt es wohl kaum, weil es nicht so eine große Modul-Ansammlung wie bei Perl
gibt (cpan). ;-)
Wenn du das sagst... (so ein Quark).

Hmm... also ich habe hier etwa 2000 Dateien in dem Unterverzeichnis "lib" im (Active-)Perl (für windows). Afaik sind das ja eine ganze Menge Perl-module. Scheinen auf den ersten Blick alles in irgendeiner Art und Weise Textdateien zu sein.

Vergleich zu PHP: Isch habe die (quelle: http://www.php.net/downloads.php) "(CGI binary plus server API versions for Apache, Apache2 (experimental), ISAPI, NSAPI, Servlet and Pi3Web. MySQL support built-in, many extensions included, packaged as zip)"-Version.
Mehr als 60 Extensions scheinen da nicht dabei gewesen zu sein. Gibt es noch richtig viel mehr? Hmm... tja, auf http://www.php.net habe ich da keine große Übersicht gesehen, von "cpan für php" habe ich auch noch nie etwas gehört. Gibt es wirklich sooooooooo viele? Und wenn, wo?

Aber eine ganze Menge Dinge bzw. extensions können afaik in php "mitkompiliert" werden
beim kompilieren des interpreters.
Tatsächlich müssen sämtliche Extensions in PHP zum Interpreter dazukompiliert werden. Die
Extensions-Einträge sind nichts anderes als eine Umsetzung mit dynamischem dazubinden.
Technisch das gleiche.
Ja, sozusagen. Aber letztenendes macht dl(modulblabla); in etwa vergleichbares wie
"use ..." in perl.
Nein. use macht viel mehr. perldoc Exporter. perldoc perlmod.

Ewig viel Text ;-). Ok, ich glaube dir ja schon, dass PHP nicht ein annähernd so entwickeltes Modulsystem wie Perl hat (vor allem gibt es bei PHP ja afaik nicht diese einfachen packages, dass eine PHP-Datei mit ein paar Auszeichnungen zu einem "Package" werden kann).

Letztenendes gibt es in perl afaik auch keine perl.ini oder vergleichbares, sodass man
das cgi-modul auch wieder in jeder perl-datei hinzuladen muss, wenn man Perl nur
für CGI-Programmierung benutzt.
So wie es sinnvoll ist.

hmm... wenn man perl wirklich ausschließlich für die CGI-Programmierung nutzt und _immer_ das cgi-modul geladen haben will, dann wäre ein "standartladen" des cgi-moduls überaus sinnvoll, oder!?

Gäbe es bei PHP ein CGI-Modul (was selbstverständlich unnötig ist),
Es *gibt* ein CGI-Modul.

wie? wo?

dann könnte man es ganz einfach in der php.ini automatisch einbinden.
Und dann damit leben, dass man es auch laedt, wenn man es nicht braucht.

Stimmt, bei Linux wird Perl auch auch in Shellscripten und so nem Zeugs verwendet, da braucht man es nicht, klar. Aber ansonsten - .

Gruß,
WauWau