Prüfung ob Variable vorhanden

[Roland]

Hallo,

bisher mache if folgendes.

if (isset($_GET(p))

   $p = $_GET(p);

else ...…

Ginge auch

if (isset($p =$_GET(p))

?

Gruß Roland

[Rolf b]

Probier's doch aus 😉.

Jedoch:

• $_GET ist ein Array, keine Funktion, daher brauchst Du eckige Klammern statt runde. War bestimmt ein Tippfehler im Forum…
• Es ist eine Unsitte, alphanumerische Keys von Arrays nicht in Anführungszeichen zu schreiben. Sollte irgendwer mal den Key per define mit einem Wert belegen, fliegst Du aus der Kurve.

Richtig ist also ausschließlich dies: $p = $_GET['p'];

Das in ein isset hineinzusetzen geht aber nicht. isset ist keine Funktion, sondern ein Sprachkonstrukt und erwartet eine Variable oder ein Array-Element. Eine Expression geht nicht. Die Fehlermeldung verrät auch gleich die Lösung des Problems:

<b>Fatal error</b>:  Cannot use isset() on the result of an expression (you can use "null !== expression" instead) ... <br />

Rolf

[Tabellenkalk]

Hallo,

isset ist keine Funktion,

hm, ich finde isset() im PHP-Manual unter function.isset.php, in der "function reference" im Abschnitt mit der Bezeichnung "Variable handling Functions". Magst du deine Behauptung überdenken?

Gruß
Kalk

[Rolf b]

Nö. Guck auf die von Dir verlinkte Seite unter "Notes".

Rolf

[Tabellenkalk]

Hallo,

Nö. Guck auf die von Dir verlinkte Seite unter "Notes".

Nagut, ich weiß zwar nicht, warum solch Information als Anmerkung soweit unten versteckt sein muss, aber so sei es.

Gruß
Kalk

[dedlfix]

Tach!

Nagut, ich weiß zwar nicht, warum solch Information als Anmerkung soweit unten versteckt sein muss, aber so sei es.

Weil sie für den Verwender nicht ganz wichtig ist. Die Verwendung entspricht ja formal auch der einer Funktion.

isset() lässt sich aber nicht als Funktion implementieren, weil es sonst den üblichen Beschränkungen von Funktionen unterworfen wäre. Beispielsweise, dass eine Notice-Fehlermeldung beim Zugriff auf die nicht vorhandene Variable erzeugt wird, und dass das Argument als Ausdruck zunächst berechnet werden sowie dessen Ergebnis übergeben würde, was im Falle einer einfachen Variable (oder Arrayelement) dessen Inhalt ist. isset() braucht aber den Namen der Variablen, um ohne diese Nebenwirkungen die Existenz überprüfen zu können. Und deshalb ist es keine Funktion, sondern wird gesondert von der PHP-Engine behandelt. Und deshalb kann man da auch keinen zu berechnenden Ausdruck angeben. Schon gar nicht so wie im Falle des OP

isset($p = $_GET['p'])

Wovon soll denn isset() die Existenz ermitteln, von $p oder von $_GET['p']? Wenn man da Ausdrücke angeben dürfte, könnten die beliebig komplex sei und eine Menge Variablen enthalten.

Was der OP stattdessen sucht, ist wohl eher empty() und PHP ab Version 5.5. Das verarbeitet seit dieser Version auch Ausdrücke und wirft ebenfalls keine Fehlermeldungen.

dedlfix.

[Auge]

Hallo

bisher mache if folgendes.

if (isset($_GET(p))

   $p = $_GET(p);

else ...…

Abgesehen von der falschen Syntax („()“ statt „[]“ um den Namen des Array-Schlüssels und den fehlenden Anführungszeichen um den selbigen Namen) stellt sich für den Einzelfall die Frage, ob das umkopieren von $_GET['p'] nach $p notwendig und/oder sinnvoll ist. Oft ist es das nicht. Zudem wäre hier interessant, was sich im else-Zweig verbirgt.

Ginge auch

if (isset($p =$_GET(p))

?

Nein, das funktioniert nicht. Du kannst, wenn du Blöcke vermeiden willst, aber den ternären Operator benutzen.

$p = (isset($_GET['p']) ? $_GET['p'] : NULL;

Der Code weist $p den Wert von $_GET['p'] zu oder, wenn $_GET['p'] nicht existiert, Null (False wäre an dieser Stelle eine andere Möglichkeit).

Tschö, Auge

[Linuchs]

$p = (isset($_GET['p']) ? $_GET['p'] : NULL;

Bei mir können Parameter per get oder post reinkommen:

$p = (isset($_GET['p']) ? $_GET['p'] : $_POST['p'];

Wenn weder get noch post, ist $p NULL.

Linuchs

[Rolf b]

Nicht ganz - wenn weder $_GET noch $_POST, ist $p zwar null, aber ggf. hast Du auch eine Notice auf dem Bildschirm, weil PHP beim Zugriff auf nicht existente Array-Indexe eine raushaut.

Wenn Dir Notices egal sind (weil unterdrückt), kannst Du Dir das Leben ab PHP 7 mit dem null coalescing operator weiter vereinfachen:

$p = $_GET['p'] ?? $_POST['p'];

Rolf

[Julius]

Hallo Rolf,

Wenn Dir Notices egal sind (weil unterdrückt), kannst Du Dir das Leben ab PHP 7 mit dem null coalescing operator weiter vereinfachen:

$p = $_GET['p'] ?? $_POST['p'];

Laut Manual ist der Operator ein 1:1-Ersatz für if(isset())-Konstrukte und wirft keine Notices, auch wenn der Array-Index nicht existiert:
„In particular, this operator does not emit a notice if the left-hand side value does not exist, just like isset(). This is especially useful on array keys.“

Gruß
Julius

[Linuchs]

$p = $_GET['p'] ?? $_POST['p'];

Ah ja, das ist dann die Kurzform für (nur gelegentlich genutzt)💯

(Doppelpunkt - Enter gibt ein "komisches" Zeichen)

$p = (isset($_GET['p'])  ? $_GET['p']
    :((isset($_POST['p']) : $_POST['p'] ? NULL );

Linuchs

[dedlfix]

Tach!

(Doppelpunkt - Enter gibt ein "komisches" Zeichen)

Doppelpunkt - Escape - Enter ergibt einen Doppelpunkt.

Die Vorschlagsliste kann man abbrechen, wenn man sie die angebotenen Möglichkeiten nicht möchte. Manchmal stört sie eben, aber daran kann man sich gewöhnen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Die Vorschlagsliste kann man abbrechen, wenn man sie die angebotenen Möglichkeiten nicht möchte. Manchmal stört sie eben, aber daran kann man sich gewöhnen.

Meh! Nutzerfeindliche Denke detected.

Die Lösung wäre, die Vorschlagliste nicht auf ein häufig vorkommendes Zeichen wie : zu legen.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Die Lösung wäre, die Vorschlagliste nicht auf ein häufig vorkommendes Zeichen wie : zu legen.

Weniger Arroganz. Das ist keine Lösung, da man durchaus :-) autovervollständigen will zu 😀. Die Lösung muss ausgetüftelter sein.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Das ist keine Lösung, da man durchaus :-) autovervollständigen will zu 😀. Die Lösung muss ausgetüftelter sein.

Die Liste bei der Kombination :- anzeigen?

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Das ist keine Lösung, da man durchaus :-) autovervollständigen will zu 😀. Die Lösung muss ausgetüftelter sein.

Die Liste bei der Kombination :- anzeigen?

Ist auch nur eine halbe Lösung. Die Schreibweise :) (u.a.) wird auch gerne benutzt.

Aber ja, das erst bei mehr als : ausgelöst wird halte ich auch für eine mögliche Lösung.

LG,
CK

[Rolf b]

Doppelpunkt SPACE macht die Liste wieder zu, das ist ok. Kann man als ersten Eintrag in der Vorschlagsliste einfach den Doppelpunkt einbauen? Dann würde Doppelpunkt ENTER einen Doppelpunkt liefern. Ich denke, dass damit die häufigsten „Nerv-Fälle“ abgedeckt wären.

Rolf

[Christian Kruse]

Hallo Rolf,

Doppelpunkt SPACE macht die Liste wieder zu, das ist ok. Kann man als ersten Eintrag in der Vorschlagsliste einfach den Doppelpunkt einbauen? Dann würde Doppelpunkt ENTER einen Doppelpunkt liefern. Ich denke, dass damit die häufigsten „Nerv-Fälle“ abgedeckt wären.

Das ist eine ziemlich gute Idee.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Kann man als ersten Eintrag in der Vorschlagsliste einfach den Doppelpunkt einbauen? Dann würde Doppelpunkt ENTER einen Doppelpunkt liefern.

Das ist wohl eher ein Hack denn eine Lösung.

Das ist eine ziemlich gute Idee.

Finde ich nicht.

Ein Dialogfenster, das gar nicht erst aufgehen sollte, sollte gar nicht erst aufgehen.

Wir sollten überlegen, wann es gewünscht ist, dass das Dialogfenster aufgeht. Das beïnhaltet auch die Frage, ob das Dialogfenster beim Tippen überhaupt aufgehen soll.

Wenn die Kombinatiion :- zuwenig ist wegen :), dann kann man diese Kombination ja auch noch abfangen. Und :( …

LLAP 🖖

PS: Wird nicht :- in Lisp für irgendwas verwendet?

[Rolf b]

beïnhaltet

Keine Sorge, ich rühre deine Stelzen nicht an 😜

Das beïnhaltet auch die Frage, ob das Dialogfenster beim Tippen überhaupt aufgehen soll.

D.h. deine Präferenz wäre ein Hotkey oder ein Button, der bei zu kurzer Codelänge die Code-Liste manuell öffnet, ggf ergänzt durch eine Abfrage, die bei hinreichend langem Code die Codeliste anbietet?

Wenn die Kombinatiion :- zuwenig ist wegen :), dann kann man diese Kombination ja auch noch abfangen. Und :( …

Du denkst bei all dem auch noch an (a) den Programmieraufwand und (b) an den User, der ggf. gar nicht mehr kapiert warum die Liste mal aufgeht und mal nicht? Ich weiß, wer Usability wünscht, will das nicht gegen Aufwand aufgerechnet sehen, aber Arbeit ist es trotzdem.

Rolf

[Gunnar Bittersmann]

@@Rolf b

beïnhaltet

Keine Sorge, ich rühre deine Stelzen nicht an 😜

IMHO ein Fall, wo „beïnhaltet“ passt; „enthält“ aber nicht so richtig. Siehste, @MudGuard!

D.h. deine Präferenz wäre ein Hotkey oder ein Button, der bei zu kurzer Codelänge die Code-Liste manuell öffnet, ggf ergänzt durch eine Abfrage, die bei hinreichend langem Code die Codeliste anbietet?

Button überm Eingabefeld, ja.

Wenn’s denn auch beim Tippen angeboten werden soll, dann bei Zeichenkombationen, die mit ziemlicher Sicherheit zu einem Smiley führen sollen. Und Kombationen der Länge 2 sollten reichen.

Meine Präferenz? Ich brauche das Zeug gar nicht. Ich bin mit „Emoji und Symbole einblenden“ (macOS) bzw. dem Umschalten der Tastatur (iOS) bestens bedient. Da finde ich, was ich suche. In der aufploppenden Auswahlliste eher nicht.

Du denkst bei all dem auch noch an (a) den Programmieraufwand

Wenn ein Feature hohen Aufwand erfordert, um es vernünftig umsetzen, dann sollte man entweder den Aufwand betreiben oder das Feature sein lassen, aber nicht versuchen, mit wenig Aufwand irgendwas zu implementieren, das dann nichts Halbes und nichts Ganzes ist.

und (b) an den User, der ggf. gar nicht mehr kapiert warum die Liste mal aufgeht und mal nicht?

Meine Idee war’s nicht, ein Dialogfenster beim Tippen aufploppen zu lassen. Ob das für manche sinnvoll ist oder nicht wage ich nicht so richtig zu beurteilen, da – wie gesagt – für mich das Feature nicht sinnvoll ist.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Zeichenkombationen […] Und Kombationen

Gunnars erste Regel über Tippfehler: Tippfehler treten bevorzugt dort auf, wo sie sich durch copy and paste am besten vermehren können.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Wir sollten überlegen, wann es gewünscht ist, dass das Dialogfenster aufgeht. Das beïnhaltet auch die Frage, ob das Dialogfenster beim Tippen überhaupt aufgehen soll.

Siehe Slack, siehe Bulletin-Boards. Ja, sollte es und ja, auch bei :. Denn das entspricht den Nutzer-Erwartungen. </Gunnar>

PS: Wird nicht :- in Lisp für irgendwas verwendet?

Meines Wissens nach zumindest nicht in Elisp.

LG,
CK

[Christian Kruse]

Hallo Christian,

Wir sollten überlegen, wann es gewünscht ist, dass das Dialogfenster aufgeht. Das beïnhaltet auch die Frage, ob das Dialogfenster beim Tippen überhaupt aufgehen soll.

Siehe Slack, siehe Bulletin-Boards. Ja, sollte es und ja, auch bei :. Denn das entspricht den Nutzer-Erwartungen. </Gunnar>

Tut mir leid, das kam vielleicht als Seitenhieb rüber. Das war aber nicht so gemeint, ich hatte witzeln wollen (aber den Smiley vergessen).

LG,
CK

[Christian Kruse]

Hallo Gunnar,

ich habe da mal was gebastelt. Es gibt jetzt einen Button in der Toolbar und das autocomplete geht nur noch auf wenn man mehr als ein Zeichen eingibt nach dem Doppelpunkt.

PS: Wird nicht :- in Lisp für irgendwas verwendet?

Zumindest in Bash script setzt man damit einen Default-Wert für eine Variable.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Weniger Arroganz.

Sag ich doch.

Vom Nutzer zu verlangen, sich der Technik anzupassen, anstatt andersrum die Technik an den Nutzer anzupassen, ist Arroganz des Entwicklers gegenüber den Nutzern.

(Und das ganz allgemein, ohne hier mit dem Finger auf jemanden zeigen zu wollen. Weil davor kaum ein Entwickler gefeit ist.)

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

ich versuche es doch nochmal… vielleicht kommt ja doch noch etwas Verständigung dabei herum.

Weniger Arroganz.

Sag ich doch.

Ich sprach von deiner Eigenart, deine Sichtweise und deine Ideen als die absolute Wahrheit darzustellen. Etwa hier:

Die Lösung wäre, die Vorschlagliste nicht auf ein häufig vorkommendes Zeichen wie : zu legen.

Das unterstellt erstens, dass das tatsächlich die richtige Lösung ist (trotz der Tatsache, dass es hier keine richtige Lösung geben kann, sondern nur Kompromisse: die Autovervollständigung wird nie vollständig nerv-frei sein) sondern auch, dass ich nicht darüber nachgedacht habe, was hier die beste Lösung sein könnte.

Keine Ahnung, ob du das beabsichtigt hast, aber es gibt ein paar einfache Mittel, das zu vermeiden. Du hättest hier z.B. eine mögliche Lösung scheint mir zu sein … schreiben können.

Vom Nutzer zu verlangen, sich der Technik anzupassen, anstatt andersrum die Technik an den Nutzer anzupassen, ist Arroganz des Entwicklers gegenüber den Nutzern.

Ob das hier der Fall ist kannst du aber nicht beurteilen. Ich habe meine Gedankengänge bezüglich der Wahl von : nicht offengelegt, du hast also keine Erkenntnisse darüber, ob ich vielleicht das Zeichen gewählt habe weil ich es für den besseren Kompromiss hielt. Das ist hier z.B. der Fall, der : ist De-Facto-Standard für Emojis, ausgelöst durch die Bulletin-Boards und weiter verbreitet durch Slacks Siegeszug.

(Und das ganz allgemein, ohne hier mit dem Finger auf jemanden zeigen zu wollen. Weil davor kaum ein Entwickler gefeit ist.)

Natürlich nicht. Das ist mir bewusst. Und eine gewissen Anpassung ist manchmal durchaus auch notwendig. Das jedoch zu hinterfragen und in Frage zu stellen finde ich gut und richtig, natürlich treffe ich auch falsche Entscheidungen bei der Entwicklung, etwa weil ich nicht alles überblicke. Man kann das aber auch tun ohne ständig jemanden vor den Kopf zu stoßen. Ich stecke hier eine Menge Freizeit in dieses Projekt, da kann ich das, finde ich, durchaus erwarten.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Weniger Arroganz.

Sag ich doch.

Ich sprach von deiner Eigenart […]

Hach, dachte ich’s mir doch, dass du dir was anderes dachtest als ich herauslesen wollte. 😆

Vom Nutzer zu verlangen, sich der Technik anzupassen, anstatt andersrum die Technik an den Nutzer anzupassen, ist Arroganz des Entwicklers gegenüber den Nutzern.

Ob das hier der Fall ist kannst du aber nicht beurteilen. Ich habe meine Gedankengänge […]

Ich hatte dich hier überhaupt nicht im Sinn. Ich bezog mich auf dedlfix’ Aussage „Manchmal stört sie [die Vorschlagliste] eben, aber daran kann man sich gewöhnen.“

Nutzer soll sich an etwas Störendes gewöhnen. Ähm, nein.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Hach, dachte ich’s mir doch, dass du dir was anderes dachtest als ich herauslesen wollte. 😆

War mir klar, dass dir das klar war 😂

Vom Nutzer zu verlangen, sich der Technik anzupassen, anstatt andersrum die Technik an den Nutzer anzupassen, ist Arroganz des Entwicklers gegenüber den Nutzern.

Ob das hier der Fall ist kannst du aber nicht beurteilen. Ich habe meine Gedankengänge […]

Ich hatte dich hier überhaupt nicht im Sinn.

Dass du nicht an mich gedacht hast, hab ich mir schon gedacht 😉

Nein, im Ernst. Du hast doch über meine Software geschrieben. Wie kannst du denn realistisch davon ausgehen, dass ich deine Aussage nicht darauf beziehe? Du hast hier doch einen sehr eindeutigen Kontext.

Abgesehen davon wird das, was ich geschrieben habe, dadurch ja auch nicht invalide…?

LG,
CK

[dedlfix]

Tach!

Nutzer soll sich an etwas Störendes gewöhnen. Ähm, nein.

Ähm, doch. Ich weiß nicht, warum es hier ein kompromissloses Nein geben sollte. Einige Nutzer stört es, dass diese Liste aufgeht. Andere Nutzer stört es, wenn es diese Liste nicht gäbe. Was immer du machst, irgendwelche Nutzer werden sich immer an irgendetwas stören. Wie löst ein Nein dieses Dilemma?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Nutzer soll sich an etwas Störendes gewöhnen. Ähm, nein.

Ähm, doch. Ich weiß nicht, warum es hier ein kompromissloses Nein geben sollte.

Technik soll sich dem Menschen anpassen, nicht andersrum.

Einige Nutzer stört es, dass diese Liste aufgeht. Andere Nutzer stört es, wenn es diese Liste nicht gäbe. Was immer du machst, irgendwelche Nutzer werden sich immer an irgendetwas stören. Wie löst ein Nein dieses Dilemma?

Mit der richtigen™ Fragestellung ist das Problem kein Dilemma mehr.

Nicht: Einige Nutzer stört es, dass diese Liste aufgeht.
Sondern: Einige Nutzer stört es, wann diese Liste aufgeht.

Wenn man in diese Richtung weiterdenkt, findet man womöglich eine Lösung, ohne eine Nutzergruppe gegen eine andere auszuspielen.

LLAP 🖖

[dedlfix]

Tach!

Wenn man in diese Richtung weiterdenkt, findet man womöglich eine Lösung, ohne eine Nutzergruppe gegen eine andere auszuspielen.

Na das ist doch schon mal ein guter Ansatz. Den solltest du auch gegenüber den Entwicklern berücksichtigen.

dedlfix.

[dedlfix]

Tach!

Die Vorschlagsliste kann man abbrechen, wenn man sie die angebotenen Möglichkeiten nicht möchte. Manchmal stört sie eben, aber daran kann man sich gewöhnen.

Meh! Nutzerfeindliche Denke detected.

Ich bin an dieser Stelle der Nutzer. Und ich muss und möchte auch nicht ständig in Windeln gepackt werden.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich bin an dieser Stelle der Nutzer.

Ein Nutzer.

LLAP 🖖

[dedlfix]

Tach!

Ich bin an dieser Stelle der Nutzer.

Ein Nutzer.

Gut erkannt. Warum meinst du, für alle Nutzer gleichermaßen sprechen zu können?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich bin an dieser Stelle der Nutzer.

Ein Nutzer.

Gut erkannt. Warum meinst du, für alle Nutzer gleichermaßen sprechen zu können?

Schlecht erkannt. Ich habe hier nirgends „für alle Nutzer gleichermaßen“ gesprochen, sondern für diejenigen, die von Entwicklern gerne mal übersehen werden, weil sie anders ticken als Entwickler sich das so vorstellen.

LLAP 🖖

[dedlfix]

Tach!

Schlecht erkannt. Ich habe hier nirgends „für alle Nutzer gleichermaßen“ gesprochen, sondern für diejenigen, die von Entwicklern gerne mal übersehen werden, weil sie anders ticken als Entwickler sich das so vorstellen.

Ach! Das hab ich aus dem "Meh! Nutzerfeindliche Denke detected." aber so detailliert nicht entnehmen können.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Schlecht erkannt. Ich habe hier nirgends „für alle Nutzer gleichermaßen“ gesprochen, sondern für diejenigen, die von Entwicklern gerne mal übersehen werden, weil sie anders ticken als Entwickler sich das so vorstellen.

Ach! Das hab ich aus dem "Meh! Nutzerfeindliche Denke detected." aber so detailliert nicht entnehmen können.

„Nutzerfeindliche Denke“ meint nicht:

an alle Nutzer nicht gedacht.

„Nutzerfeindliche Denke“ meint:

nicht an alle Nutzer gedacht.

LLAP 🖖

[dedlfix]

Tach!

„Nutzerfeindliche Denke“ meint:

nicht an alle Nutzer gedacht.

Das ist mir auch unmöglich. Aber nicht, weil ich auf Seiten der Entwickler arbeite, sondern weil die Vielfalt der Individualitäten zu groß ist.

Es ist auch nicht so, dass ich nur bis zu meinem eigenen Tellerrand denke. Ich suche schon nach Lösungen, aber auch nach Kompromissen. Und ich weiß auch, dass viele Nutzer nicht stur sind, sondern sich nach anfänglichen Problemen durchaus auch arrangieren können. Nicht jede Technik lässt sich so anpassen, dass sie allen Interessengruppen gleichermaßen gerecht wird.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Und ich weiß auch, dass viele Nutzer nicht stur sind, sondern sich nach anfänglichen Problemen durchaus auch arrangieren können.

Können schon. Der Punkt ist, dass sie es nicht sollten müssen.

Nicht jede Technik lässt sich so anpassen, dass sie allen Interessengruppen gleichermaßen gerecht wird.

Yep. Mit Betonung auf „gleichermaßen“.

Mit anderen Worten: Technik sollte sich so anpassen lassen, dass sie allen Interessengruppen auf ihre jeweils eigene Weise gerecht wird.

Wird ja hier im Forum mit den Nutzereinstellungen auch praktiziert. (Womit ich jetzt nicht sagen will, dass ich einen Schalter für Vorschlagliste an/aus in den Nutzereinstellungen für eine gute Lösung dieses Problems halte.)

LLAP 🖖

[Rolf b]

Laut Manual ist der Operator ein 1:1-Ersatz für if(isset())-Konstrukte und wirft keine Notices, auch wenn der Array-Index nicht existiert

Cool, wieder was gelernt :)

Aber wenn der Key in $_POST auch fehlt, wird der Zugriff darauf immer noch eine Notiz schicken. Man muss also nur ein weiteres Mal koaleszieren und ist Notice-befreit:

$p = $_GET['p'] ?? $_POST['p'] ?? NULL;

Rolf

[Julius]

Hallo Rolf,

Aber wenn der Key in $_POST auch fehlt, wird der Zugriff darauf immer noch eine Notiz schicken. Man muss also nur ein weiteres Mal koaleszieren und ist Notice-befreit:

$p = $_GET['p'] ?? $_POST['p'] ?? NULL;

Äh ja, stimmt. Gut, dass es hier meist jemanden gibt, dem sowas auffällt 😀.

Gruß
Julius

[Encoder, schon wieder nicht benutzbar]

Was mir hier noch fehlt, die Betrachtung deines Konstrukts if (isset($a = $b). Unabhängig von Sinn und Syntax.

Hier wird zuerst (!!!) die Zuweisung gemacht, danach erfolgt die Prüfung ob ein existierender Wert zugewiesen wurde. In deinem ersten Beispiel prüfst du zuerst ob $b gesetzt ist und weist dann das an $a zu.
Diese beiden Verhalten sind also etwas fundamental anderes.

[Matthias Apsel]

Hallo Encoder, schon wieder nicht benutzbar,

„schon wieder nicht benutzbar“ klingt

a) negativ und
b) so, als ob das Problem auf der Seite des Forums läge.

Warum ist das Forum nicht benutzbar?

Bis demnächst
Matthias

[Rolf b]

Wenn man die Sache ganz fundamentalistisch und kontextfrei betrachtet, hast Du natürlich recht. Wenn $p vorher schon einen relevanten Wert enthielte, der im Falle eines fehlenden $_GET['p'] beibehalten werden muss, würde die if (!isset($p=$_GET['p'])` diesen Wert verlieren.

Da es hier aber eher danach aussieht, einen Default für einen nicht übergebenen Parameter zu finden, ist der Unterschied irrelevant.

Rolf