[PHP] Condities

[g4wx3]

PHP:

$month = 1;
$day = 1;
$newyear = (($month == 12 and $day>=27) or ($month == 1 and $day<=5));
$newyear = ($month == 12 and $day>=27) or ($month == 1 and $day<=5);

Code om een banner te laten zien bepaalde dagen.

De eerste lijn doet wat wordt verwacht, de 2de lijn niet.
kan iemand het effect van de "overbodige" haakjes verklaren?

// een betere methode om hetzelfde te bereiken mag ook

[Thralas]

Kijk eens heel goed naar het tabelletje hier: http://php.net/manual/en/language.operators.precedence.php

[Verwijderd]

Ik weet niet waarom het niet zou werken maar beide lijnen evalueren als:

lijn 1: false || true ? true
lijn 2: false || true ? true

Zou hetzelfde moeten zijn als:

PHP:

$newyear = $month == 12 && $day >= 27 || $month == 1 && $day <= 5;

Evalueert ook gewoon hetzelfde?

[Fish]

http://stackoverflow.com/questions/9346174/php-date-between

klink Overzichterlijker

[Onbekend]

In PHP is

PHP:

$newyear = ($month == 12 && $day>=27) || ($month == 1 && $day<=5);

anders dan

PHP:

$newyear = ($month == 12 and $day>=27) or ($month == 1 and $day<=5);

Zelf ben ik ook niet echt blij dat PHP de tweede variant gewoon accepteert, maar ik raad je gewoon aan om || en &&-operaters te gebruiken.

[ Voor 37% gewijzigd door Onbekend op 25-12-2014 19:41 ]

[NMe]

Onbekend schreef op donderdag 25 december 2014 @ 19:39:
Zelf ben ik ook niet echt blij dat PHP de tweede variant gewoon accepteert, maar ik raad je gewoon aan om || en &&-operaters te gebruiken.

Je gebruikt ze in andere situaties. De veelgebruikte "or die()" is misschien wel het bekendste voorbeeld. Overigens is het daarmee nog geen goed idee om die operator te gebruiken, ook niet op die manier. Ik heb hem zelf in 8 jaar professioneel webdevelopment nog nooit nodig gehad.

[Verwijderd]

De "or" en "and" operators kun je op zich wel mooi gebruiken, maar je moet wel goed snappen wat ze doen.

Ik was altijd wel fan van de volgende notatie:

PHP:

DEBUG and printf("debug code here");
$this->connect() or $this->shutdown();

Ook assert() werkt mooi met zo'n constructie. In productie of acceptatie wil je sommige code niet raken.
Je moet ze gewoon totaal anders gebruiken dan && en || en je moet ze helemaal niet gebruiken als je ze niet snapt.

[GlowMouse]

Verwijderd schreef op vrijdag 26 december 2014 @ 00:09:
De "or" en "and" operators kun je op zich wel mooi gebruiken, maar je moet wel goed snappen wat ze doen.

Ik was altijd wel fan van de volgende notatie:

PHP:

DEBUG and printf("debug code here");
$this->connect() or $this->shutdown();

Ook assert() werkt mooi met zo'n constructie. In productie of acceptatie wil je sommige code niet raken.
Je moet ze gewoon totaal anders gebruiken dan && en || en je moet ze helemaal niet gebruiken als je ze niet snapt.

Ik begrijp niet goed waar je op doelt, || en or zijn allebei links-associatieve short-circuit operatoren. Het enige verschil zit erin dat || eerder wordt geëvalueerd dan een or (zie de posts van Thralas en Onbekend).

[Verwijderd]

Het lijkt een klein verschil, maar dat enige verschil betekent dat je ze moet mijden als de pest tenzij je goed begrijpt wat die operators doen.
Ik zou ze nooit gebruiken om te vergelijken en alleen maar gebruiken als een soort language constructs die aan Perl en Python doen denken.

[.oisyn]

GlowMouse schreef op vrijdag 26 december 2014 @ 00:23:
[...]
Het enige verschil zit erin dat || eerder wordt geëvalueerd dan een or (zie de posts van Thralas en Onbekend).

Niet alleen dat, ze hebben een lagere precedence dan assignment, en dat is precies de reden dat je ze beter links kan laten liggen voor normale expressies want dat gaat vroeg of laat fout.

[Sendy]

En die "lager dan assignment" precedence maakt dus het probleem van de TS? Wat rechts van de or staat wordt pas na de assignment geëvalueerd?

[Patriot]

.oisyn schreef op vrijdag 26 december 2014 @ 01:10:
[...]

Niet alleen dat, ze hebben een lagere precedence dan assignment, en dat is precies de reden dat je ze beter links kan laten liggen voor normale expressies want dat gaat vroeg of laat fout.

Voor de mensen die het nog niet doorhadden, dit is de reden waarom het stukje code van de TS zich pas naar verwachting gedraagt als er om het geheel haakjes staan. Het stukje ($month == 12 && $day >= 27) voert 'ie als eerst uit, dat stopt 'ie in $newyear en pas dán gaat hij de or-operator uitvoeren en de andere vergelijking (en da's dus te laat, want dan heeft $newyear zijn waarde al).

EDIT: @hierboven; ja dus

[NMe]

Verwijderd schreef op vrijdag 26 december 2014 @ 00:09:
De "or" en "and" operators kun je op zich wel mooi gebruiken, maar je moet wel goed snappen wat ze doen.

Ik was altijd wel fan van de volgende notatie:

PHP:

DEBUG and printf("debug code here");
$this->connect() or $this->shutdown();

"Was" being voordat PHP exceptions had ofzo?

PHP:

Log::debug('debug code here');
try
{
    $this->connect();
}
catch (ConnectionFailedException $e)
{
    Log::error('Connection failed');
    $this->shutdown();
}

Het heeft wat meer volume zo, maar in een framework met de juiste log targets lijkt het me aardig de voorkeur hebben boven and en or.

[Onbekend]

De methode met "or $this->shutdown();" of "or die();" vind ik meestal te kortaf.

Meestal bouw je in php een website op en om halverwege de opbouw te stoppen is niet netjes.
Meestal gebruik ik zoiets:

PHP:

try
{
    $this->connect();
}
catch (ConnectionFailedException $e)
{
    $this->shutdown();
    echo "An unexpected error has occurred and we'll fix this error soon. There's nothing wrong with your web browser.";
    WriteFooter();
    exit;
}
Anders gaat hij evengoed door met overige bewerkingen.

[Verwijderd]

Onbekend schreef op vrijdag 26 december 2014 @ 23:25:

Meestal bouw je in php een website op en om halverwege de opbouw te stoppen is niet netjes.

En vervolgens post je een stuk code waarbij je meerdere ranzige dingen doet. Ik kan me in de opmerking van NMe wel vinden, maar in die van jou niet.

NMe schreef op vrijdag 26 december 2014 @ 13:22:
"Was" being voordat PHP exceptions had ofzo?

Nee hoor, maar exceptions moet je wat mij betreft gebruiken voor iets dat niet mis hoort te gaan, niet in een normale flow.

PHP:

function connect() {
  $rval = true;
  try
  {
    # Do something interesting
  }
  catch (ConnectionFailedException $e)
  {
    Log::error('Connection failed');
    $rval = false;
  }
  return $rval;
}

Zo vervuil je andere code niet met exceptions, logging, etcetera. Als je gewoon documenteert dat een method true of false returnt heb je ook geen exceptions en logging buiten je method nodig. Scheelt weer wat bloat in de rest van de applicatie.

Dit is natuurlijk allemaal vreselijk offtopic. Ik gaf wat voorbeelden van constructies waarin je and en or kunt gebruiken. Wil je dat niet, dan is dat ook prima en moet je ze gewoon helemaal niet gebruiken, want veel andere valide use cases zijn er niet.

[.oisyn]

PHP:

if ($a = functie() and $b = functie2())
    doeIets($a, $b);

Scheelt weer haakjes

Dit zou ik zelf overigens nooit zo toepassen. Ik ben op zich wel van de assignment binnen de conditie van de if, maar dan gewoon met haakjes. Maar goed, ik programmeer dan ook voornamelijk in C++ waar je 'and' en 'or' niet op die manier hebt.

[ Voor 54% gewijzigd door .oisyn op 27-12-2014 00:07 ]

[NMe]

Verwijderd schreef op vrijdag 26 december 2014 @ 23:52:
[...]

Nee hoor, maar exceptions moet je wat mij betreft gebruiken voor iets dat niet mis hoort te gaan, niet in een normale flow.

offtopic:
Mee eens hoor, maar ik wilde wat code laten zien die zo dicht mogelijk bij het origineel lag om zo wat duidelijker te zijn in waar ik op doelde. Uiteindelijk komt het er in elk geval op neer dat je met andere middelen duidelijker je doel bereikt dan met die rare and- en or-operators.

[Onbekend]

Verwijderd schreef op vrijdag 26 december 2014 @ 23:52:
En vervolgens post je een stuk code waarbij je meerdere ranzige dingen doet. Ik kan me in de opmerking van NMe wel vinden, maar in die van jou niet.

Ik doelde meer op het afhandelen van een fout zelf en niet voor de try-catch-constructie.

[Patriot]

.oisyn schreef op zaterdag 27 december 2014 @ 00:05:

PHP:

if ($a = functie() and $b = functie2())
    doeIets($a, $b);

Scheelt weer haakjes

Dit zou ik zelf overigens nooit zo toepassen. Ik ben op zich wel van de assignment binnen de conditie van de if, maar dan gewoon met haakjes. Maar goed, ik programmeer dan ook voornamelijk in C++ waar je 'and' en 'or' niet op die manier hebt.

Mwoa, de werking van 'and' en 'or' zoals ze in PHP werken is niet echt een argument tegen het gebruik van assignment binnen de conditie van een if, toch?

Ik heb ook niet het idee dat mensen uitgesproken tegen een bewuste assignment in een conditie van een if zijn. Eventueel vernomen afkeer is denk ik meer afkomstig van het 'omgekeerde', ik denk dat iedereen op één of ander moment wel eens langer dan 'ie durft toe te geven bezig is geweest met een bug veroorzaakt door onbewuste assignment in de conditie van een if

[.oisyn]

Patriot schreef op maandag 29 december 2014 @ 06:28:
[...]


Mwoa, de werking van 'and' en 'or' zoals ze in PHP werken is niet echt een argument tegen het gebruik van assignment binnen de conditie van een if, toch?

Dat zeg ik toch ook niet? Ik zeg dat ik juist wel fan ben van het doen van assignments binnen de conditie van de if. Ik zou alleen in PHP daar nooit 'and' of 'or' voor gebruiken, want dan is het alleen maar verwarrend bij het lezen van de code.

[NMe]

.oisyn schreef op maandag 29 december 2014 @ 11:27:
[...]

Dat zeg ik toch ook niet? Ik zeg dat ik juist wel fan ben van het doen van assignments binnen de conditie van de if. Ik zou alleen in PHP daar nooit 'and' of 'or' voor gebruiken, want dan is het alleen maar verwarrend bij het lezen van de code.

...te meer omdat zelfs veel ervaren PHP-developers die ik ken niet goed op de hoogte zijn van de verschillen tussen and/&& en or/||.

[Patriot]

.oisyn schreef op maandag 29 december 2014 @ 11:27:
[...]

Dat zeg ik toch ook niet? Ik zeg dat ik juist wel fan ben van het doen van assignments binnen de conditie van de if. Ik zou alleen in PHP daar nooit 'and' of 'or' voor gebruiken, want dan is het alleen maar verwarrend bij het lezen van de code.

Oh, sorry, ik vatte je opmerking dat je voornamelijk in C++ programmeerde op als "dus voor mij is het geen probleem, in PHP zou ik het waarschijnlijk niet doen". Verkeerd opgevat dus