[php] expr ? statement : statement

[Precision]

PHP:

class Form
{
    private $name = null;
    public function addName($name)
    {
        $this->name = $name;
    }
    
    public function getName()
    {
        if(isset($this->name))
            return $this->name;
        return null;
    }

//...
//en nog veel meer methods
    
    public function getHTML()
    {
        $output = "<input type=\"".$this->getType()."\" ".(!empty($this->getName)) ? "name=\"".$this->getName()."\"" : "".">";
        $output .= ...;
        return $output;
    }
}

echter als ik met het expr ? statement : statement werk krijg ik de error: Can't use method return value in write context, alles gaat goed zolang ik zo werk:

PHP:

public function getHTML()
{
   $test = null;
   (!empty($test)) ? "a" : "b";
   return "iets";
}

doe ik echter zo:

PHP:

public function testReturn()
{
   return;
}

public function getHTML()
{
   (!empty($this->testReturn())) ? "a" : "b";
   return "iets";
}

dan gaat het dus fout en krijg ik de error: Can't use method return value in write context.

Het is een zeer vervelend probleem ik heb niet veel zin om tussen variabelen te gebruiken of mijn $output op te gaan splitsen in if ... else statements omdat ik zo direct met een 20 - 30 regels statements ga zitten. En dit voor iemand anders rommelig is

[BtM909]

Heeft het er niet mee te maken dat Emtpy niet de return value van een functie of method kan checken?

[RobIII]

edit:
Hmmmm, misschien toch even nog een keer je topicstart lezen

[ Voor 90% gewijzigd door RobIII op 24-11-2008 17:34 ]

[Snake]

PHP:

<?php
public function testReturn()
{
   return;
}

public function getHTML()
{
   (!empty($this->testReturn())) ? "a" : "b";
   return "iets";
}
?>

Dit is zowiezo fout. Het resultaat van je evaluatie wijs je niet toe.

[Osiris]

BtM909 schreef op maandag 24 november 2008 @ 17:27:
Heeft het er niet mee te maken dat Emtpy niet de return value van een functie of method kan checken?

quote: http://nl.php.net/empty

Note: empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

Maarja, is een variabele in een object ook niet 'slechts een variabele'?

[Herko_ter_Horst]

Ik snap even niet wat je precies wilt. empty() checkt of een variable "empty" is. Als je een method hebt die iets test, waarom laat je die dan niet true/false opleveren, of een andere waarde waarop je kunt checken?

[Precision]

@ BtM909, bedankt voor zeer snelle reactie
ahja juist ja, ik zat even op compleet verkeerde spoor ...
($this->Test() != null)?"a":"b";
werkt wel, waarom ben ik daar niet eerder opgekomen, waarschijnlijk omdat het tijd is voor een pauze
het antwoord stond eigenlijk voor mijn neus ik heb het zelf getypt, nuja het nut van forum is nogmaals bewezen, iemand anders met frisse kijk ziet het direct.

bedankt voor alle reacties, fijn dat er direct massaal op gereageerd werd

[ Voor 9% gewijzigd door Precision op 24-11-2008 17:42 ]

[Precision]

Snake schreef op maandag 24 november 2008 @ 17:30:

PHP:

<?php
public function testReturn()
{
   return;
}

public function getHTML()
{
   (!empty($this->testReturn())) ? "a" : "b";
   return "iets";
}
?>

Dit is zowiezo fout. Het resultaat van je evaluatie wijs je niet toe.

dit is ook maar om te testen, het staat dan ook niet in de context waar het gebruikt wordt, was soort van voorbeeld a, voorbeeld b, sorry als dit niet duidleijk was

[Depress]

Je hebt simpelweg een ) te veel na je empty.

PHP:

(!empty($this->getName)) ? "name=\"".$this->getName()
//wordt:
(!empty($this->getName) ? "name=\"".$this->getName())

[ Voor 66% gewijzigd door Depress op 24-11-2008 21:47 . Reden: Code added ]

[Jaap-Jan]

code:

(!empty($this->getName))

Dit kan niet kloppen.

Depress schreef op maandag 24 november 2008 @ 21:45:
Je hebt simpelweg een ) te veel na je empty.

PHP:

(!empty($this->getName)) ? "name=\"".$this->getName()
//wordt:
(!empty($this->getName) ? "name=\"".$this->getName())

Volgens mij heeft 'ie een '(' te weinig en heb je het alleen maar erger gemaakt.

[ Voor 75% gewijzigd door Jaap-Jan op 24-11-2008 21:48 ]

[Verwijderd]

Als ik de error zo lees moet je $this->testReturn eerst aan een variabel hangen, en je haakjes zijn fout.

PHP:

$var = $this->testReturn();
echo (!empty($var) ? 'a' : 'b');

[ Voor 14% gewijzigd door Verwijderd op 24-11-2008 21:49 ]

[Snake]

Verwijderd schreef op maandag 24 november 2008 @ 21:48:
Als ik de error zo lees moet je $this->testReturn eerst aan een variabel hangen, en je haakjes zijn fout.

PHP:

$var = $this->testReturn();
echo (!empty($var) ? 'a' : 'b');

Waarschijnlijk is het zo iets idioot.

Net gelijk je een functie die een array niet returned niet kan accessen op index van die array. Ook idioot.

[user109731]

empty is dan ook een language construct en geen functie, vergelijkbaar met isset.
Staat gewoon in de handleiding:

quote: http://nl.php.net/empty

Note: empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

edit: hm Osiris noemde het ook al

[ Voor 5% gewijzigd door user109731 op 24-11-2008 23:06 ]

[.oisyn]

Snake schreef op maandag 24 november 2008 @ 22:25:
[...]

Waarschijnlijk is het zo iets idioot.

Net gelijk je een functie die een array niet returned niet kan accessen op index van die array. Ook idioot.

Dat laatste is idioot, dat eerste niet. Met empty test je een variabele. Niet de waarde van een variabele, en dus ook niet het resultaat van een expressie. Logisch ook, want als de variabele niet bestaat is de expressie ongeldig.

[MLM]

sidenote: ik ben misschien niet bekend genoeg met PHP, maar de ? : operator is toch essentieel een assignment operator, dus

C++:

int a = some_expr() ? 1 : 2;

maar als je de result van de operator niet gebruikt, volstaat het evalueren van de expressie

[Woy]

MLM schreef op dinsdag 25 november 2008 @ 09:18:
sidenote: ik ben misschien niet bekend genoeg met PHP, maar de ? : operator is toch essentieel een assignment operator, dus

C++:

int a = some_expr() ? 1 : 2;

maar als je de result van de operator niet gebruikt, volstaat het evalueren van de expressie

je hoeft volgens mij niet perse te assignen

PHP:

!empty( $var ) ? DoSomething( $var ) : DoDefault();

Is volgens mij ook gewoon correct ( maar ben ook geen PHP expert ), maar in veel talen is het idd een assignment

[ Voor 3% gewijzigd door Woy op 25-11-2008 09:32 ]

[.oisyn]

Nee, er is niets "assignments" aan. Het is gewoon een expressie, die afhankelijk van het eerste operand de tweede of de derde evalueert. Gewoon een verkapte if-then-else als expressie dus. Dit werkt immers ook:

PHP:

func($a > 10 ? 1 : 2);

Als je dit een assignment noemt dan is de + operator bijvoorbeeld ook een assignment.

[ Voor 15% gewijzigd door .oisyn op 25-11-2008 12:07 ]

[Woy]

.oisyn schreef op dinsdag 25 november 2008 @ 12:06:
Nee, er is niets "assignments" aan. Het is gewoon een expressie, die afhankelijk van het eerste operand de tweede of de derde evalueert. Gewoon een verkapte if-then-else als expressie dus. Dit werkt immers ook:

PHP:

func($a > 10 ? 1 : 2);

Als je dit een assignment noemt dan is de + operator bijvoorbeeld ook een assignment.

Ok het is inderdaad een expressie, ik had moeten zeggen dat het vaak geen valide Statement op zichzelf is.

In bijvoorbeeld C# mag het volgende niet ( als los statement dus )

C#:

myBool ? Foo() : Bar();

Volgens mij heb ik dat wel eens in PHP gezien dat dat wel mocht, maar dat weet ik dus niet zeker.

[.oisyn]

Dat lijkt me wel raar, elke expressie is valide als statement in de meeste C-dialecten. Gewoon a+b als statement mag ook. Komt het niet gewoon omdat Foo en Bar void returnen? In C++ mag dat namelijk gewoon (als ze iets anders dan void returnen)

[ Voor 13% gewijzigd door .oisyn op 25-11-2008 12:24 ]

[Woy]

.oisyn schreef op dinsdag 25 november 2008 @ 12:23:
Dat lijkt me wel raar, elke expressie is valide als statement in de meeste C-dialecten. Gewoon a+b als statement mag ook. Komt het niet gewoon omdat Foo en Bar void returnen?

Deze code

C#:

void Test()
{
    true ? Foo() : Bar();
}

object Foo()
{
    return new object();
}

object Bar()
{
    return new object();
}

levert deze compile error op

Only assignment, call, increment, decrement, and new object expressions can be used as a statement

Ik was er eerst ook verbaasd over, maar dacht dat het dus ook in c/c++ etc zo was . Blijkbaar niet dus.

C#:

int a, b;
a + b;

mag dus ook niet in C#. Op zich ook niet zo vreemd als je defineert dat de + geen side effects op a en b moet hebben.

In C++ mag dat namelijk gewoon (als ze iets anders dan void returnen)

Waarom mag het wel als ze iets returnen ( Waar niks mee gedaan word ), en niet als ze void returnen?

[ Voor 28% gewijzigd door Woy op 25-11-2008 12:42 ]

[user109731]

rwb schreef op dinsdag 25 november 2008 @ 12:37:
mag dus ook niet in C#. Op zich ook niet zo vreemd als je defineert dat de + geen side effects op a en b moet hebben.

Het kan wel handig zijn icm operator overloading zoals in C++:

C++:

foo << bar;

Waarom mag het wel als ze iets returnen ( Waar niks mee gedaan word ), en niet als ze void returnen?

Ik denk omdat je 'void' niet kunt toewijzen aan een variabele of kunt gebruiken in een expressie. ?: moet altijd een waarde opleveren, maar dat kan niet als 1 van de 'takken' naar void evalueert.

[ Voor 11% gewijzigd door user109731 op 25-11-2008 13:14 ]

[Woy]

JanDM schreef op dinsdag 25 november 2008 @ 13:02:
[...]
Het kan wel handig zijn icm operator overloading zoals in C++:

C++:

foo << bar;

Ja maar daar veraderd de << operator foo dus wel. Ik bedoelde dat als je de + operator defineert zodat die geen invloed heeft op de operands, dat het dan ook een onzinnig statement is.

Ik denk omdat je 'void' niet kunt toewijzen aan een variabele of kunt gebruiken in een expressie. ?: moet altijd een waarde opleveren, maar dat kan niet als 1 van de 'takken' naar void evalueert.

O ja natuurlijk.

[.oisyn]

rwb schreef op dinsdag 25 november 2008 @ 12:37:
Waarom mag het wel als ze iets returnen ( Waar niks mee gedaan word ), en niet als ze void returnen?

scratch dat, het mag wel. Het punt is meer dat de ?: operator zelf ook weer iets moet returnen, wat niet kan als de twee functies void returnen. Maar dat kan wel, het resultaat van de ?: is dan ook void. Maar de twee types moeten wel compatible zijn (of om precies te zijn, het type van de derde expressie moet impliciet converteerbaar zijn naar het type van de tweede expressie)

JanDM schreef op dinsdag 25 november 2008 @ 13:02:
Ik denk omdat je 'void' niet kunt toewijzen aan een variabele of kunt gebruiken in een expressie.

Dat laatste kan wel (waardoor ik ook wel kon vermoeden dat het natuurlijk wel werkte met ?: ). Dit mag ook:

C++:

void a() { }
void b() { return a(); }

Als je het niet kon gebruiken dan kon je ook geen void functies aanroepen (dat zijn immers expressies die void opleveren). Je mag alles ook gewoon casten naar void (wat in bovenstaande voorbeeld zou moeten als a() bijv. een int zou returnen)

[ Voor 51% gewijzigd door .oisyn op 25-11-2008 13:58 ]

[farlane]

.oisyn schreef op dinsdag 25 november 2008 @ 12:06:
Nee, er is niets "assignments" aan. Het is gewoon een expressie, die afhankelijk van het eerste operand de tweede of de derde evalueert. Gewoon een verkapte if-then-else als expressie dus. Dit werkt immers ook:

PHP:

func($a > 10 ? 1 : 2);

Als je dit een assignment noemt dan is de + operator bijvoorbeeld ook een assignment.

Hmm, kan me herinneren dat het gebruiken van ?: voor zijn side-effects nou niet echt als good practice wordt gezien.

Imho : Als je if_then_else bedoeld gebruik dan ook if_then_else.

[edit]
Daarmee bedoel ik niet het voorbeeld dat je hier geeft maar de vorm waarin de TS het gebruikt.

[ Voor 7% gewijzigd door farlane op 25-11-2008 14:09 ]

[user109731]

.oisyn schreef op dinsdag 25 november 2008 @ 13:53:
Als je het niet kon gebruiken dan kon je ook geen void functies aanroepen (dat zijn immers expressies die void opleveren).

Hm natuurlijk, stom dat ik daar niet aan dacht

De topic titel is ook een beetje vreemd, een statement kan niet in een expressie

[ Voor 3% gewijzigd door user109731 op 25-11-2008 14:28 ]

[Woy]

.oisyn schreef op dinsdag 25 november 2008 @ 13:53:
[...]
(of om precies te zijn, het type van de derde expressie moet impliciet converteerbaar zijn naar het type van de tweede expressie)

In C# hoeft dat niet precies op die manier. Daar is

C#:

class Foo
{
}

class Bar : Foo
{
}
Foo foo = expression ? new Bar() : new Foo();

ook valide omdat het target type Foo is.

[farlane]

Derived is toch ook impliciet te converteren naar Base?

[Woy]

farlane schreef op dinsdag 25 november 2008 @ 14:50:
Derived is toch ook impliciet te converteren naar Base?

Derived wel naar Base, maar Base niet naar Derived.

Het type van de 2 expressie is Bar en daar is Foo niet (impliciet of expliciet) naar te converteren. .oisyn gaf aan dat het in c/c++

het type van de derde expressie moet impliciet converteerbaar zijn naar het type van de tweede expressie

Wat in mijn voorbeeld dus niet opgaat, maar wel in C# kan

[user109731]

Heb het even opgezocht, in C# werkt het zo:

Let X and Y be the types of the second and third operands. Then,

* If X and Y are the same type, then this is the type of the conditional expression.
* Otherwise, if an implicit conversion exists from X to Y, but not from Y to X, then Y is the type of the conditional expression.
* Otherwise, if an implicit conversion exists from Y to X, but not from X to Y, then X is the type of the conditional expression.
* Otherwise, no expression type can be determined, and a compile-time error occurs.

Dit is dus het tweede geval

[Woy]

JanDM schreef op dinsdag 25 november 2008 @ 15:00:
Heb het even opgezocht, in C# werkt het zo:

[...]

Dit is dus het tweede geval

Inderdaad, bij de volgende code weet hij er geen raad meer mee

C#:

class Foo
{
    public static implicit operator Bar(Foo input)
    {
        return new Bar();
    }
}

class Bar
{
    public static implicit operator Foo ( Bar input )
    {
        return new Foo();
    }
}
Foo foo = expression ? new Bar() : new Foo();

Dan komt de logische melding

Type of conditional expression cannot be determined because 'Bar' and 'Foo' implicitly convert to one another

[ Voor 3% gewijzigd door Woy op 25-11-2008 15:13 ]

[farlane]

rwb schreef op dinsdag 25 november 2008 @ 15:12:
[...]

Inderdaad, bij de volgende code weet hij er geen raad meer mee

C#:

class Foo
{
    public static implicit operator Bar(Foo input)
    {
        return new Bar();
    }
}

class Bar
{
    public static implicit operator Foo ( Bar input )
    {
        return new Foo();
    }
}
Foo foo = expression ? new Bar() : new Foo();

Dan komt de logische melding

[...]

Op zich wel vreemd, beide statements zijn te converteren naar Foo, het type waar je het aan toekent.

[.oisyn]

Toekennig doet er niet toe, een subexpressie staat compleet los van de context waarin ie gebruikt wordt. De ?: wordt dus eerst geevalueerd, en pas daarna wordt gekeken of het resultaat van de ?: wel compatible is met de assignment. Maar de ?: zelf is al ambigu, vandaar de error.

[Snake]

.oisyn schreef op woensdag 26 november 2008 @ 01:00:
Toekennig doet er niet toe, een subexpressie staat compleet los van de context waarin ie gebruikt wordt. De ?: wordt dus eerst geevalueerd, en pas daarna wordt gekeken of het resultaat van de ?: wel compatible is met de assignment. Maar de ?: zelf is al ambigu, vandaar de error.

Dat snap ik niet?

Waarom is die ?: zelf ambigu?

En zowiezo begrijp ik niet waarom C# daarover moeilijk doet.

[Woy]

Snake schreef op woensdag 26 november 2008 @ 08:03:
[...]

Dat snap ik niet?

Waarom is die ?: zelf ambigu?

En zowiezo begrijp ik niet waarom C# daarover moeilijk doet.

Omdat de types beide kanten op te converteren zijn. Als ze er dan bijvoorbeeld gewoon het type van de eerste pakken is het volgende niet meer waar.

true ? A : B == false ? B : A

Het word dan ook een beetje onvoorspelbaar gedrag. Uit de Quote van JanDM volgt natuurlijk ook meteen dit gedrag. Ook komt het natuurlijk niet vaak voor dat je 2 weg impliciete conversies hebt, meestal gaat die maar een kant op, en de andere kant is een expliciete conversie ( Widening/Narrowing Conversions )

[.oisyn]

rwb schreef op woensdag 26 november 2008 @ 08:59:
[...]

Omdat de types beide kanten op te converteren zijn. Als ze er dan bijvoorbeeld gewoon het type van de eerste pakken is het volgende niet meer waar.

true ? A : B == false ? B : A

Does that matter? Nergens staat dat ?: commutatief moet zijn. C#'s manier heeft zowel voordelen als nadelen tov C++'s manier. Het voordeel is idd dat de volgorde niet boeit en dat je dus ook kunt beginnen met een type dat converteerbaar is naar de andere (in C++ heb je dan een expliciete cast nodig, of je moet de operands (en de conditie) omdraaien). Het nadeel is dat daardoor wel ambiguities kunnen ontstaan, zoals in bovenstaand voorbeeld.

[farlane]

Wat zijn in C++ de officiele regels dan want als ik de MSDN beschrijving van MS lees dan lijkt die toch erg sterk op de C# versie:

If both expressions are of pointer types or if one is a pointer type and the other is a constant expression that evaluates to 0, pointer conversions are performed to convert them to a common type.

Er staat dus niet zozeer dat de derde naar de tweede geconverteerd wordt.

[.oisyn]

Hmm, blijkbaar zit ik er naast. C++ doet het idd zoals C# het ook doet. Ik kan me toch sterk herinneren dat ik hier ooit eens ruzie mee had met VC++.

[prototype]

rwb schreef op dinsdag 25 november 2008 @ 12:37:
[...]

C#:

int a, b;
a + b;

mag dus ook niet in C#. Op zich ook niet zo vreemd als je defineert dat de + geen side effects op a en b moet hebben.

Erm, wat hebben side effects (i.e. state changes) hiermee te maken? :-)

In ruby wordt dit overigens gewoon toegestaan, i.e.:

Ruby:

def groter
    puts "groter"
end

def kleiner
    puts "kleiner"
end

a = 5
b = 4
(a > b) ? groter : kleiner

In het geval van C# is denk ik de beredenering dat type conversie mogelijk moet zijn, maar imho zou dit hoe dan ook altijd mogelijk moeten zijn m.u.v. void expressies: casten naar Object (evt als boxed type) in het geval dat de types in de ternary expressie niet specifieke typevarianten van elkaar zijn, i.e. geen specifiekere gemeenschappelijke contravariant type hebben dan Object.

[ Voor 17% gewijzigd door prototype op 27-11-2008 04:27 ]

[farlane]

.oisyn schreef op woensdag 26 november 2008 @ 16:47:
Hmm, blijkbaar zit ik er naast. C++ doet het idd zoals C# het ook doet. Ik kan me toch sterk herinneren dat ik hier ooit eens ruzie mee had met VC++.

Het stuk komt uit de docs van VC2008 volgens mij dus het zou best kunnen dat een oudere versie wat "beperkter" was

[Woy]

prototype schreef op donderdag 27 november 2008 @ 04:25:
Erm, wat hebben side effects (i.e. state changes) hiermee te maken? :-)

Ik bedoel dat als de + operator geen wijzigingen uitvoert op a of b, a + b een zinloos statement is en dus niet gek dat het niet is toegestaan.

In het geval van C# is denk ik de beredenering dat type conversie mogelijk moet zijn, maar imho zou dit hoe dan ook altijd mogelijk moeten zijn m.u.v. void expressies: casten naar Object (evt als boxed type) in het geval dat de types in de ternary expressie niet specifieke typevarianten van elkaar zijn, i.e. geen specifiekere gemeenschappelijke contravariant type hebben dan Object.

Op zich zou er wat voor te zeggen zijn als er idd naar de "Grootst gemene deler" gecast zou worden, worst case zou dat idd object zijn.

Maar opzich is dat in deze ook mogelijk, alleen dan moet je een van de twee explicieet naar object moeten casten.