Undefinierte Funktion

[Gaby]

Hallo, ganz zu Beginn meines PHP-Scripts steht:

session_start();
rahmen = 'N';
session_register("rahmen");

Und dies führt zu dem Fehler

Fatal error: Uncaught Error: Call to undefined function session_register()

Woran kann dies liegen?

[J o]

Hey,

session_start();
rahmen = 'N';
session_register("rahmen");

Und dies führt zu dem Fehler

Fatal error: Uncaught Error: Call to undefined function session_register()

Woran kann dies liegen?

Wahrscheinlich, da wie im Manual steht, es ab PHP version 5.4.0 entfernt wurde und du eine höhere Version nutzt.

Besser also:

$_SESSION['rahmen'] = 'N';

Falls das nicht so sein sollte, vielleicht das fehlende $``rahmen.

Gruß
Jo

[Rolf B]

Hallo Jo,

das fehlende $ würde zu einem Syntax Error führen und dürfte daher beim Kopieren ins Forum entstanden sein.

Also: Die PHP Version ist zu neu. session_register ist verfault. Das ist leider bei PHP so, diese Sprache ist so morsch, dass sich regelmäßig ein paar Funktionen in Staub auflösen.

Alt-Code und Alt-Beispiele gehen dann einfach mal durch ein Sprachupdate kaputt.

Rolf

[J o]

Hey,

das fehlende $ würde zu einem Syntax Error führen und dürfte daher beim Kopieren ins Forum entstanden sein.

Ja, das ist mir nach dem Bearbeiten auch aufgefallen, konnte es dann aber nicht mehr ändern.

Gruß
Jo

[Henry]

Hallo Rolf,

Das ist leider bei PHP so, diese Sprache ist so morsch, dass sich regelmäßig ein paar Funktionen in Staub auflösen.

Hey, mach mir mein PHP nicht schlecht… 😉 Ohne PHP wäre ich nie zum programmieren gekommen, Perl hatte mich vorher bereits total demotiviert. Mit PHP ging dann auf einmal alles so einfach und logisch… "I love PHP"

Gruss
Henry

[1unitedpower]

"I love PHP"

Das hört man auch nicht so oft. Aber schön, wenn sie dir gefällt, lass das mal die Entwickler hören, die könnten sicher ein wenig Wundbalsam vertragen.

[pl]

hi,

Also: Die PHP Version ist zu neu. session_register ist verfault. Das ist leider bei PHP so, diese Sprache ist so morsch, dass sich regelmäßig ein paar Funktionen in Staub auflösen.

Alt-Code und Alt-Beispiele gehen dann einfach mal durch ein Sprachupdate kaputt.

Nicht ein Beispiel bezüglich Perl will mir hierzu einfallen. Das liegt hauptsächlich aber daran daß es Funktionen wie schick_mir_mal_ne_mail() oder hol_mir_mal_ne_flasche_bier() in Perl nie gegeben hat.

MfG

[1unitedpower]

Alt-Code und Alt-Beispiele gehen dann einfach mal durch ein Sprachupdate kaputt.

Nicht ein Beispiel bezüglich Perl will mir hierzu einfallen.

Das glaube ich dir gern, aber es existieren zahlreiche Beispiele - und das ist etwas Gutes an Perl. Keine Programmiersprache ist perfekt, Perl ist da keine Ausnahme, es gehört zur Aufgabe von Sprachdesigner(innen) die faulen Features zu erkennen und auszumisten. Mit Perl 6 wurde zuletzt ein sehr gründlicher Frühjahrsputz gemacht, aber ich vermute aus deinen letzten Perl-Postings, dass du noch nicht umgestiegen bist. Wie übrigens viele Perl-Programmierer, das ist leider die Kehrseite der Medaille, einige Programmierer bleiben auf der Strecke oder suchen sich Alternativen, weil sie mit der Weiterentwicklung einer Sprache nicht einverstanden sind oder sich nicht weiterentwickeln wollen oder ihnen keine entsprechenden Bildungsmöglichkeiten vom Arbeitgeber ermöglicht werden, oder… Das müssen Sprachdesigner(innen) alles berücksichtigen, die Leute hinter PHP fahren einen sehr konservativen Kurs, weil man Angst hat die Nutzerbasis zu verlieren. Es ist schwieriger Leute zurückzugewinnen als sie zu vergraulen. Die Python-Entwickler(innen) haben es zu gut gemeint, und mit dem Versionssprung auf Python 3 viele ihrer Entwickler(innen) nicht abholen können, weshalb sie jetzt zwei Major-Versionen parallel pflegen. Bei Perl 5 und 6 zeichnet sich momentan ein ähnliches Bild ab. Dazu kommt der Druck auf die Designer(innen), der von neuen, modernen Programmiersprachen ausgeübt wird.

[Regina Schaukrug]

Die Python-Entwickler(innen) haben es zu gut gemeint, und mit dem Versionssprung auf Python 3 viele ihrer Entwickler(innen) nicht abholen können.

Ja. Hier mal ein Beispiel für die, die es nicht wissen.

Man stelle sich vor, man habe unternehmenskritische Anwendungen programmiert, die sich womöglich auch noch über mehrere hundert (oder tausende) libs verteilen, von denen ein Teil "nur einmal im Jahr benutzt wird, aber im Fehlerfall zum Untergang führen kann".

Man folgte brav den alten Styleguides ... und dann passiert sowas:

# Python 2 only:
print 'Hello'

# Python 2 and 3:
print('Hello')

Es kostet einfach eine Menge Arbeit (und viele, viele, womöglich sehr aufwendige Tests) um dann von Python 2 auf Python 3 zu wechseln. Dann hat man ganz schnell den von Dir genannten Konflikt zwischen "alten" Anwendern (die sowas natürlich nicht wollen) und neuen Anwendern, die natürlich ganz klar sagen, dass wenn, print eine Funktion ist, die Argumente wie bei jeder anderen Funktion in ein Klammerpaar gehören.

Mir selbst kommt es vor, als sei PHP da anwenderfreundlicher (Abgesehen natürlich insbesondere vom "hauptschülergerechten" Umgang mit Variablen und Datentypen).

Allerdings gibt es da noch mehr Brüche:

$pos = strpos ( $haystack , $needle );

Mir fällt sofort auf, dass daran was verkehrt ist. Alle anderen (Funktionen) suchen nämlich die Nadel im Heuhaufen. Aus meiner Sicht ein Designfehler- und der ist im Hinblick auf abertausende existierende Skripte auch "nachträglich nicht mehr korrigierbar".

Denn eine "leicht baubare" Krücke wie

function myStrpos ( $needle , $haystack ) {
    return strpos ( $haystack , $needle );
}

$pos = myStrpos ( $needle , $haystack );

würde im Ergebnis des Programmierprozesses nur zu noch mehr Fehlern führen, weil dann gar keiner mehr weiß in welcher Reihenfolge die Argumente denn angegeben werden müssen.

Es gibt mit Sicherheit andere, die an PHP oder anderen Programmiersprachen anderes stört. Aber was ich hier zeige sind Probleme, die schon in Skripten auf Hello-World-Niveau auftreten und schwer zu vermitteln sind.

[Henry]

Hallo Regina,

Mir selbst kommt es vor, als sei PHP da anwenderfreundlicher (Abgesehen natürlich insbesondere vom "hauptschülergerechten" Umgang mit Variablen und Datentypen).

Ja sehr anwenderfreundlich… Den Rest halte ich aber für anmaßend und herablassend.

Allerdings gibt es da noch mehr Brüche:

$pos = strpos ( $haystack , $needle );

Mir fällt sofort auf, dass daran was verkehrt ist. Alle anderen (Funktionen) suchen nämlich die Nadel im Heuhaufen. Aus meiner Sicht ein Designfehler- und der ist im Hinblick auf abertausende existierende Skripte auch "nachträglich nicht mehr korrigierbar".

Ja da hat wohl einer die Reihenfolge vertauscht, hat mich aber nie gestört.

Denn eine "leicht baubare" Krücke wie

function myStrpos ( $needle , $haystack ) {
    return strpos ( $haystack , $needle );
}

$pos = myStrpos ( $needle , $haystack );

Wofür? Ist es nicht leichter sich die Reihenfolge zu merken oder im Zweifelsfall mal kurz nachzuschlagen?

würde im Ergebnis des Programmierprozesses nur zu noch mehr Fehlern führen, weil dann gar keiner mehr weiß in welcher Reihenfolge die Argumente denn angegeben werden müssen.

Nö.

Es gibt mit Sicherheit andere, die an PHP oder anderen Programmiersprachen anderes stört. Aber was ich hier zeige sind Probleme, die schon in Skripten auf Hello-World-Niveau auftreten und schwer zu vermitteln sind.

Das ist kein Problem. Ich kann mich noch gut an die Anfangszeit erinnern. PC war für mich ein rotes Tuch, Fachbegriffe waren für mich verbale Hieroglyphen, war froh, dass ich an und aus machen konnte. Irgendwann kam das Internet, da wollte ich mich dann doch mal mehr damit beschäftigen, und ich verstand im Laufe der Zeit immer mehr(HTML und Windows). Aber dann wollte ich natürlich auch scriptbasierte Anwendungen haben, mit Müh und Not, hier und da was in Perl/CGI hinbekommen. Zwischendurch auch mal c++ und anderes probiert, alles mit mäßigem Erfolg. Dann kam PHP. Auch das vertand ich nicht auf Anhieb, die Bücher waren grottenschlecht, was oft der Fall ist wenn Profis einem Anfänger etwas vermitteln wollen, aber gar nicht mehr wissen wie dieser denkt und welche Fragen sich für den auftun. Meine Hürde waren Semikolon, Klammer und der Punkt, wann, wieso, Auswirkung, usw…

Bald bekam ich ein besseres Buch in die Hand, und der wusste genau wie Anfänger denken, es war dann nur noch ein Klacks. Dann kam noch ein Buch, glaube "PHP gepackt", da standen nur, ähnlich dem Manual, die Funktionen drin. Jackpot! Ab da ging's rasant weiter. Was ich nicht wusste kurz mal nachschlagen und passende Funktion finden/kombinieren, einfach effizient.

In jedem Fall immer leicht nachvollziehbar und niemals "problematisch" weil irgendeine Argumentenreihenfolge anders als erwartet ist. Das dürfte auch allenfalls nur bei Leuten auftreten, die oft mehrere Sprachen nutzen und keine Lust haben ständig umzudenken, vermute ich mal, oder einfach vor lauter Frust(ich will das aber anders....) eine Gedächnisblockade erzeugen.

Gruss
Henry

[Regina Schaukrug]

Hallo Regina,

Mir selbst kommt es vor, als sei PHP da anwenderfreundlicher (Abgesehen natürlich insbesondere vom "hauptschülergerechten" Umgang mit Variablen und Datentypen).

Ja sehr anwenderfreundlich… Den Rest halte ich aber für anmaßend und herablassend.

Naja. Das nimmt Bezug auf die nicht ganz scherzhafte Umschreibung des Akronyms durch "pubertierende Hauptschüler programmieren". Und der Umgang von PHP mit Variablen ist halt so, dass er darauf ausgerichtet ist, ein Ergebnis statt einer Fehlermeldung zu erzeugen, also quasi "das Bemühen ergebnisunabhängig zu loben". Denn das Ergebnis ist dann einfach mal sehr oft falsch - und es wird oft nur eine Notiz geloggt. Der Anwender bekommt das regelmäßig gar nicht mit und vertraut - womöglich mit teuren Folgen - auf das Ergebnis dieser, ich nenn's mal, "Unart kybernetischen Bemühens". Das ist längst nicht nur aus meiner Sicht ein katastrophales Verhalten, welches (wohl und/oder auch) zu der einleitend erwähnten Umschreibung (die nicht von mir stammt) geführt hat.

Das dürfte auch allenfalls nur bei Leuten auftreten, die oft mehrere Sprachen nutzen

... dazu gehöre ich ...

und keine Lust haben ständig umzudenken, vermute ich mal, oder einfach vor lauter Frust(ich will das aber anders....) eine Gedächnisblockade erzeugen.

Ich weiß ja nicht, wie Dein Gedächtnis funktioniert, aber ich bin nicht der "krasse Auswendiglerntyp", eher ein "Wissensvernetzer". Mein Gedächtnis honoriert es ergo wenn die Reihenfolge der Argumente festen Regeln folgt (Hier: Nadel, Heuhaufen) und nicht derart grundlos abweicht. Was strpos() betrifft habe ich mir das natürlich "sehr genau gemerkt" - und vor allem ist jedes Vorkommen von strpos() ein "heißer" Kandidat für die Suche nach logischen Fehlern.

[Matthias Apsel]

Hallo Henry,

da wollte ich mich dann doch mal mehr damit beschäftigen,

mehr(HTML und Windows).
vor lauter Frust(ich will das aber anders....)

weil ich das schon ganz oft von dir gesehen habe: Vor eine öffnende Klammer gehört auch ein Leerzeichen. Es sei denn, es handelt sich um eine Wortergänzung wie Programmierer(in), nicht aber Frankfurt (Oder).

Die Wikipedia-Beispiele finde ich gut, weil allumfassend:

Vor einer öffnenden und nach einer schließenden Klammer wird stets ein Leerzeichen gesetzt (außer es folgt – wie hier – ein Satzzeichen oder die Klammer kennzeichnet Alternativen wie in Kolleg(inn)en).

Nach einer öffnenden und vor einer schließenden Klammer dagegen nicht. (Ein Satzpunkt steht vor einer schließenden Klammer nur dann, wenn ein kompletter Satz – wie hier – eingeklammert ist.)

Bis demnächst
Matthias

[pl]

hi,

# Python 2 only:
print 'Hello'

# Python 2 and 3:
print('Hello')

Es kostet einfach eine Menge Arbeit (und viele, viele, womöglich sehr aufwendige Tests) um dann von Python 2 auf Python 3 zu wechseln. Dann hat man ganz schnell den von Dir genannten Konflikt zwischen "alten" Anwendern (die sowas natürlich nicht wollen) und neuen Anwendern, die natürlich ganz klar sagen, dass wenn, print eine Funktion ist, die Argumente wie bei jeder anderen Funktion in ein Klammerpaar gehören.

In Perl kein Problem, eigene Funktionen werden vorher bekanntgegeben :

# stub
sub foo;

foo 1,2,3;
sub foo{  print "@_" } # 1 2 3

und schon klappt der Aufruf ohne Klammern.

MfG

[pl]

hi,

Alt-Code und Alt-Beispiele gehen dann einfach mal durch ein Sprachupdate kaputt.

Nicht ein Beispiel bezüglich Perl will mir hierzu einfallen.

Das glaube ich dir gern, aber es existieren zahlreiche Beispiele - und das ist etwas Gutes an Perl. Keine Programmiersprache ist perfekt, Perl ist da keine Ausnahme,

Doch, ist es. Guck mal hier das sind alle Perlfunktionen derzeit und von Major Release 4 her kommend, hat sich nichts großartiges geändert.

Hinzugekommen sind ab Mj.5 funktionen wie bless und package, also OOP betreffend.

es gehört zur Aufgabe von Sprachdesigner(innen) die faulen Features zu erkennen und auszumisten.

Ja sicher doch. Das wird in Perl auch getan -- aber ebenso daß am Stamm an Builtinfunktionen nicht großartig herumgsägt wird. Was grundsätzlich dem modularem Aufbau von Perl geschuldet ist: Perl ist erweiterbar, ohne daß der Kernel neu kompiliert werden muss.

Das Zauberwort hierfür heißt CPAN und die Schnittstelle XS ermöglicht das Einbinden von 3rd-Party-PLs in Perlcode wie c und Python.

Mit Perl 6 wurde zuletzt ein sehr gründlicher Frühjahrsputz gemacht,

Nein. Perl 6 ist gegenüber Mj 5 eine völlige Neuentwicklung!

aber ich vermute aus deinen letzten Perl-Postings, dass du noch nicht umgestiegen bist.

Wozu auch, ich bin Rentner. Aber an meinem, in Perl 5 entwickeltem Webframework habe ich immer wieder meine Freude.

Und ja, die Entwicklung ist an ganz anderen Stellen stehengeblieben! Was sich u.a. darin zeigt, daß man WebAnwendungen mit heutigen Anforderungen abwärtskompatibel bis Perl v.5.6.1 (Stand 2001) programmieren kann.

MfG

[1unitedpower]

Keine Programmiersprache ist perfekt, Perl ist da keine Ausnahme,

Doch, ist es.

Schön, wenn du so ein großer Fan bist.

Ja sicher doch. Das wird in Perl auch getan -- aber ebenso daß am Stamm an Builtinfunktionen nicht großartig herumgsägt wird. Was grundsätzlich dem modularem Aufbau von Perl geschuldet ist: Perl ist erweiterbar, ohne daß der Kernel neu kompiliert werden muss.

Einer Programmiersprache neue Features zu verpassen ist in der Regel ungefährlich, dadurch bleibt Abwärtskompatibilität normalerweise erhalten. Die Kunst ist es Features, die den Test der Zeit nicht bestanden haben, irgendwann rauszuwerfen ohne großen Schaden anzurichten. Das macht Perl üribgens auch, und nochmal: das ist etwas Gutes, das man als Perl-Entwickler(in) schätzen sollte.

Das Zauberwort hierfür heißt CPAN und die Schnittstelle XS ermöglicht das Einbinden von 3rd-Party-PLs in Perlcode wie c und Python.

Ich weiß, dass war zu deiner aktiven Zeit noch anders, aber heute sind Modulsysteme und Foreign Function Interfaces in fast jeder Programmiersprache vorhanden.

Mit Perl 6 wurde zuletzt ein sehr gründlicher Frühjahrsputz gemacht,

Nein. Perl 6 ist gegenüber Mj 5 eine völlige Neuentwicklung!

Perl 5 im Vergleich zu Perl 4 übrigens auch. Ich finde es beachtlich, dass die Perl-Entwickler(innen) so viel Mühe auf sich nehmen, um ihre Sprache zu verbessern.

aber ich vermute aus deinen letzten Perl-Postings, dass du noch nicht umgestiegen bist.

Wozu auch, ich bin Rentner. Aber an meinem, in Perl 5 entwickeltem Webframework habe ich immer wieder meine Freude.

Ich will dich gar nicht dazu überreden, wenn du deinen Spaß mit Perl 5 hast und nichts neues mehr lernen möchtest, ist das okay – irgendwie auch schade − aber okay. Ich erwähne Perl 6, weil das Thema hier gerade Abwärtskompatibilität lautet, und da finde ich es wichtig, über die jüngere Entwicklung einer Sprache zu reden und nicht nur in Nostalgie zu versinken.

Und ja, die Entwicklung ist an ganz anderen Stellen stehengeblieben! Was sich u.a. darin zeigt, daß man WebAnwendungen mit heutigen Anforderungen abwärtskompatibel bis Perl v.5.6.1 (Stand 2001) programmieren kann.

Für Perl 5.6 werden seit fast 15 Jahren keine Sicherheitslücken mehr geschlossen, davon würde ich also dringend abraten.