Konditionaloperator

[Chris]

Hallihallo,

ich habe ein Problem mit dem Konditionaloperator.

In einem Formular wird eine E-Mail-Adresse eingetragen. Nun will ich einen simplen Check machen, ob die Adresse gültig ist oder nicht.
Falls sie es ist, speichere ich sie in %update_data, um sie später in die DB zu schreiben.
Ist sie nicht korrekt, wird sie nicht in die DB geschrieben und stattdessen eine CSS-Klasse gesetzt, um das entsprechende input-Feld hervorzuheben.

Die Funktion ist eigentlich egal, ich habe folgendes Code-Stück:

  
  (param('email') =~ m/^\w+@\w+\.\w+$/)  
      ? $update_data{'email'} = quote(param('email'))  
      : $class{'email'} = 'invalid_value';  

Das komische ist, dass $update_data{'email'} den Wert 'invalid_value' bekommt, wenn die Adresse gültig ist (also der Regex matcht).

Woran liegt das? Ich kann es mir einfach nicht erklären.

Grüße
Chris

[Struppi]

Die Funktion ist eigentlich egal, ich habe folgendes Code-Stück:

(param('email') =~ m/^\w+@\w+.\w+$/)
      ? $update_data{'email'} = quote(param('email'))
      : $class{'email'} = 'invalid_value';

  
Das ist eine falsche Verwendung des Operators. Die richtige ist:  
  
$wert = $bedigung ? $neu\_1 : $neu\_2;  
  
Benutze eine if else Bedingung und alles ist gut.  
  
Struppi.

-- 
[Javascript ist toll](http://javascript.jstruebig.de/) (Perl auch!)

[Chris]

Das ist eine falsche Verwendung des Operators. Die richtige ist:

$wert = $bedigung ? $neu_1 : $neu_2;

Danke für die schnelle Antwort!
Schade, dass das so nicht geht. Ich finde es viel übersichtlicher.

  
$bedingung  
  ? print 'alles'  
  : print 'nix';  

funktioniert ja auch. (Aber da gehts nicht um Zuweisungen...)

Naja, Perl kann halt auch nicht alles :)

Chris

[Struppi]

Danke für die schnelle Antwort!
Schade, dass das so nicht geht. Ich finde es viel übersichtlicher.

gehen tut es du musst nur mehr Dinge beachten

$bedingung
  ? print 'alles'
  : print 'nix';

> funktioniert ja auch. (Aber da gehts nicht um Zuweisungen...)  
  
Auch das geht einfacher  
~~~perl
  
print $bedingung ? 'alles' : 'nix';  

Wie gesagt du solltest diesen Operator nicht als if else Mißbrauchen.

Struppi.

[Chris]

Hallo Struppi,

$bedingung
  ? print 'alles'
  : print 'nix';

> > funktioniert ja auch. (Aber da gehts nicht um Zuweisungen...)  
>   
> Auch das geht einfacher  
> ~~~perl
  

> print $bedingung ? 'alles' : 'nix';  
> 

Dass das einfacher geht, ist mir schon klar. Es sollte nur ein Beispiel sein, dass es manchmal auch so funktioniert, wie ich es mir dachte.

Wie gesagt du solltest diesen Operator nicht als if else Mißbrauchen.

Das ist schade, denn das wäre doch mal eine schöne Abkürzung gewesen. So verschwende ich zwei Zeilen für geschweifte Klammern :)

Würde man die Sachen nach dem '?' bzw. ':' als Anweisungen interpretieren, würde sich doch am bisherigen nichts ändern. Man kann ja "return $var;" auch zu "$var;" abkürzen, weil eben dann der Variablenwert zurückgegeben wird. Und das wäre bei

  
$wert = ($bed) ? $var1 : $var2;  

ja auch nicht anders. Führe '$var1' als Anweisung aus, dann kommt eben nur der Wert zurück, und alles passt.

Das ist es, was ich nicht verstehe, aber nun akzeptiere und brav if-else schreibe :)

Grüße
Chris

[seth_not@home]

gudn tach!

Wie gesagt du solltest diesen Operator nicht als if else Mißbrauchen.

warum nicht?

prost
seth

[Struppi]

Wie gesagt du solltest diesen Operator nicht als if else Mißbrauchen.

warum nicht?

Weil es nicht daselbe tut und zu dem gezeigten Problem führt.

Struppi.

[seth_not@home]

gudn tach!

Wie gesagt du solltest diesen Operator nicht als if else Mißbrauchen.

warum nicht?

Weil es nicht daselbe tut und zu dem gezeigten Problem führt.

das lag bloss daran, dass der OP zuwenig klammern gesetzt hat. siehe Vinzens' posting, oder eben direkt perldoc perlop.

der trinaere operator _ist_ als abkuerzende schreibweise fuer if-then-else gedacht. das ist also kein missbrauch.

prost
seth

[Struppi]

der trinaere operator _ist_ als abkuerzende schreibweise fuer if-then-else gedacht. das ist also kein missbrauch.

es ist "much like".
Aber letztlich ist es, zumindest in meinen Augen, ein Zuweisungsoperator der nach dem if else Prinzip arbeitet. Den im gegensatz zum klassischen if, hat er einen Rückgabewert und wenn man eh Klammern muss, finde ich if else übersichtlicher zumal in einem Editor, der die Schlüsselwörter hervorhebt.

Struppi.

[seth_not@home]

gudn tach!

der trinaere operator _ist_ als abkuerzende schreibweise fuer if-then-else gedacht. das ist also kein missbrauch.

es ist "much like".

eben.
und er wurde von c uebernommen. und dort wurde er (wenn ich die en. wikipedia richtig verstanden habe) von ALGOL uebernommen, und dort wiederum schrieb man naemlich:

a := if x > 0 then x else -x.

Aber letztlich ist es, zumindest in meinen Augen, ein Zuweisungsoperator der nach dem if else Prinzip arbeitet.

eigentlich ist das gleichheitszeichen der zuweisungsoperator und der ternaere operator ist nur fuer die bedingung zustaendig. zusammen kann man das dann als "conditional assignment" bezeichnen und benennt damit _eine_ anwendungsmoeglichkeit des ternaeren operators.

und wenn man eh Klammern muss, finde ich if else übersichtlicher zumal in einem Editor, der die Schlüsselwörter hervorhebt.

das darfst du ja auch unuebersichtlich finden, aber dann solltest du es imho auch explizit als deinen persoenlichen geschmack deklarieren. es las sich naemlich so, als waere es grundsaetzlich ein missbrauch, wenn man den ternaeren operator fuer bedingungen verwendete. und das ist es nicht. im perl-manual wird ja sogar explizit gesagt, wie man es "missbraucht".

prost
seth

[Struppi]

das darfst du ja auch unuebersichtlich finden, aber dann solltest du es imho auch explizit als deinen persoenlichen geschmack deklarieren. es las sich naemlich so, als waere es grundsaetzlich ein missbrauch, wenn man den ternaeren operator fuer bedingungen verwendete. und das ist es nicht. im perl-manual wird ja sogar explizit gesagt, wie man es "missbraucht".

wird es?
so wie ich das sehe nicht, mir geht es darum, dass damit unötigerweise ein Rückgabewert verworfen wird und in den Beispielen wird immer mit einer Zuweisung gearbeitet, nur bei der Erklärung warum man nicht eine Zuweisung ohne Klammer verwenden kann - also beim Mißbrauch - wird beschrieben wie man könnte, man kann ja mit Perl fast alles, sogar Objektorientiert programmieren.

Ob das tatsächlich ein Nachteil ist, den Rückgabewert zu verwerfen, weiß ich nicht, aber ich tue nicht gerne, was ich nicht muss. Und will das meinen Programmen auch nicht zumuten.

Struppi.

[seth]

gudn tach!

im perl-manual wird ja sogar explizit gesagt, wie man es "missbraucht".

wird es?

es wird gezeigt, dass man auf die klammernsetzung achten muss. es wird nirgends auch nur angedeutet, dass diese art der benutzung schlecht waere.

mir geht es darum, dass damit unötigerweise ein Rückgabewert verworfen wird

ach ja?

#!/usr/bin/perl -w  
use strict;  
my ($t, $f, $r1, $r2);  
  
if(1){  
  $r1 = $t = 'foo';  
}else{  
  $r1 = $f = 'bar';  
}  
print $r1."\n"; # prints 'foo'  
  
$r2 = (1) ? ($t='foo') : ($f='bar');  
print $r2."\n"; # prints 'foo'

es kann also in beiden faellen was zurueckgegeben werden.

man kann ja mit Perl fast alles

in diesem punkt sind wir uns zwar einig, ich halte es jedoch erst recht wegen der kettensaegen-eigenschaft von perl fuer falsch, etwas wie das benutzen des ternaeren operators, was ja sogar explizit im handbuch steht, als "missbrauch" zu bezeichnen.

Ob das tatsächlich ein Nachteil ist, den Rückgabewert zu verwerfen, weiß ich nicht,

afais wird da gar nicht mehr verworfen als beim gewoehnlichen if-then-else (siehe obiger code).

aber ich tue nicht gerne, was ich nicht muss.

so geht's mir auch, deswegen verwende ich so gerne den ternaeren operator, weil ich ja nicht das gewoehnliche if-then-else benutzen muss. ;-)

Und will das meinen Programmen auch nicht zumuten.

aha, aber du willst ihnen lieber langsameren code zumuten?
der ternaere operator scheint naemlich etwas schneller zu sein als das gewoehnliche if-then-else. ich konnte in einigen benchmarks mittels des moduls "Benchmark" jetzt zwar nichts genaues eruieren, aber das gewoehnliche if-then-else war - wohlgemekrt: ohne die explizite rueckgabe - _immer_ mind. 10% langsamer. die grossen schwankungen (teilweise waren's sogar ueber 50%) zeigen jedoch auch, dass meine cpu da an ihre mess-grenzen stoesst, wenn der kram ca. 1e6 mal pro sekunde ausgefuehrt werden kann.

ich halte fest: der ternaere operator in der verwendung ueber die wir hier reden
1. steht im handbuch (ohne negative konnotation),
2. ist nicht mehr code als if-then-else,
3. ist schneller als if-then-else.
...und du bezeichnest das als "missbrauch".

prost
seth

[Struppi]

gudn tach!

im perl-manual wird ja sogar explizit gesagt, wie man es "missbraucht".

wird es?

es wird gezeigt, dass man auf die klammernsetzung achten muss. es wird nirgends auch nur angedeutet, dass diese art der benutzung schlecht waere.

Alle Beispiel dort sind Zuweisungen, ich sehe kein Beispiel, dass den Operator als if else Ersatz empfiehlt.

mir geht es darum, dass damit unötigerweise ein Rückgabewert verworfen wird

ach ja?

#!/usr/bin/perl -w

use strict;
my ($t, $f, $r1, $r2);

if(1){
  $r1 = $t = 'foo';
}else{
  $r1 = $f = 'bar';
}
print $r1."\n"; # prints 'foo'

$r2 = (1) ? ($t='foo') : ($f='bar');
print $r2."\n"; # prints 'foo'

>   
> es kann also in beiden faellen was zurueckgegeben werden.  
  
ich seh zwar nicht, wo der if Befehl hier etwas zurück gibt, aber na gut.  
  
Für mich ist es auch ein anschauliches Beispiel, warum ich den Operator normlerweise nicht als if else Ersatz benutze, es ist unübersichtlicher weil die Schlüsselwörter fehlen und schwerer zu erkennen was passieren soll.  
  
Perl ist ja eine Programmiersprache, die sich ja an der gesprochenen Sprache orientiert, das erste Beispiel lautet:  
  
wenn 1 wahr ist weise r1 und t den String 'foo' zu, ansonsten weise r1 und f den String 'bar' zu  
  
Das zweite:  
wenn 1 wahr ist weise r1 den Rückgabewert der Zuweisung t ist der String 'foo' zu, ansonsten den Rückgabewert der Zuweisung des Strings 'foo' an f  
  

> > man kann ja mit Perl fast alles  
>   
> in diesem punkt sind wir uns zwar einig, ich halte es jedoch erst recht wegen der kettensaegen-eigenschaft von perl fuer falsch, etwas wie das benutzen des ternaeren operators, was ja sogar explizit im handbuch steht, als "missbrauch" zu bezeichnen.  
  
ich sehe nicht das das explizit im Handbuch steht, es steht dort "That should probably be written more simply as:"  
  

> > Ob das tatsächlich ein Nachteil ist, den Rückgabewert zu verwerfen, weiß ich nicht,  
>   
> afais wird da gar nicht mehr verworfen als beim gewoehnlichen if-then-else (siehe obiger code).  
  
wie gesagt ich sehe da keinen Rückgabewert des if Konstrukts, was ergibt den print if() {...};?  
Syntaxerror, also kein Rückgabewert.  
  

> > aber ich tue nicht gerne, was ich nicht muss.  
>   
> so geht's mir auch, deswegen verwende ich so gerne den ternaeren operator, weil ich ja nicht das gewoehnliche if-then-else benutzen muss. ;-)  
  
Allein schon wie das klingt, ternärer Operator, beim gewöhnlich if else (then gibt's in Perl nicht) weiß man sofort worum es geht.  
  

> > Und will das meinen Programmen auch nicht zumuten.  
>   
> aha, aber du willst ihnen lieber langsameren code zumuten?  
  
Ja sicher, im Zweifelsfall ziehe ich lesbaren Code, schnellerem vor.  
  

> ich halte fest: der ternaere operator in der verwendung ueber die wir hier reden  
> 1. steht im handbuch (ohne negative konnotation),  
  
es steht so nicht im Handbuch, es wird darauf hingewiesen wie man ihn so nutzen könnte, wobei das Beispiel unmittelbar danach den klassischen Gebrauch empfiehlt.  
  

> 2. ist nicht mehr code als if-then-else,  
  
stimm, es ist weniger.  
  

> 3. ist schneller als if-then-else.  
  
aber unlesbarer.  
  

> ...und du bezeichnest das als "missbrauch".  
  
ja, weil der Operator etwas tun soll, was ein einfaches if else nicht tut.  
Wobei mich das aber tatsächlich überrascht hat, dass der Operator soviel schneller ist. Ich werde ihn in Zukunft öfters mißbrauchen.  
  
Struppi.

-- 
[Javascript ist toll](http://javascript.jstruebig.de/) (Perl auch!)

[Hans]

Hallo !

Ich habe folgendes probiert und die "E-Mail passt !":

#!/usr/bin/perl

my $email="[e-mail]";

($email =~ m/^\w+@\w+.\w+$/)
? print "E-Mail passt !\n"
: print "E-Mail passt nicht !\n";

Hast Du mal Deine zu prüfende E-Mail-Adresse ausgegeben?

Gruß

Hans

[Chris]

Hallo Hans,

danke für deine Mühe, aber das Problem ist schon anderweitig gelöst :)

my $email="[e-mail]";

($email =~ m/^\w+@\w+.\w+$/)
? print "E-Mail passt !\n"
: print "E-Mail passt nicht !\n";

Hier verwendest du als Anweisungen prints, damit geht das auch. Bei mir waren es aber Zuweisungen und da passieren komische Dinge. Mit if-else funzt es natürlich und das hab ich auch genommen.
Warum es mit den Zuweisungen solche Probleme gibt, versteh ich zwar nicht ganz, aber man muss halt damit leben :)

Grüße
Chris

[Struppi]

my $email="[e-mail]";

($email =~ m/^\w+@\w+.\w+$/)
? print "E-Mail passt !\n"
: print "E-Mail passt nicht !\n";

Argh, das geht so

print ($email =~ m/^\w+@\w+\.\w+$/) ? "E-Mail passt !\n" : print "E-Mail passt nicht !\n";  

Hast Du mal Deine zu prüfende E-Mail-Adresse ausgegeben?

Das Porblem ist Zuweisung innerhalb des Ausdrucks.

Struppi.

[Struppi]

Argh, das geht so

print ($email =~ m/^\w+@\w+.\w+$/) ? "E-Mail passt !\n" : print "E-Mail passt nicht !\n";

  
AAAAARg,  
  
~~~perl
print ($email =~ m/^\w+@\w+\.\w+$/) ? "E-Mail passt !\n" : "E-Mail passt nicht !\n";  

Struppi.

[Hans]

Argh, das geht so

print ($email =~ m/^\w+@\w+.\w+$/) ? "E-Mail passt !\n" : print "E-Mail passt nicht !\n";

>   
> AAAAARg,  
>   
> ~~~perl

print ($email =~ m/^\w+@\w+\.\w+$/) ? "E-Mail passt !\n" : "E-Mail passt nicht !\n";  

> 

Hammer's jetzt bald? ;-)

Gruß

Hans

[Vinzenz Mai]

Hallo,

(param('email') =~ m/^\w+@\w+.\w+$/)
      ? $update_data{'email'} = quote(param('email'))
      : $class{'email'} = 'invalid_value';

  
ich sehe Zuweisungen ohne Verwendung von Klammern.  
  
Die  Perldoc erzählt Dir im Abschnitt [Conditional Operator](http://perldoc.perl.org/perlop.html#Conditional-Operator-operator%2c-conditional-operator%2c-ternary-ternary-%3f%3a)  
  
"Because this operator produces an assignable result, using assignments without parentheses will get you in trouble."  
  
und erläutert dies an einem einfach zu verstehenden Beispiel.  
  

> Das komische ist, dass $update\_data{'email'} den Wert 'invalid\_value' bekommt, wenn die Adresse gültig ist (also der Regex matcht).  
>   
> Woran liegt das? Ich kann es mir einfach nicht erklären.  
  
Ich folgere daraus, dass Du das Handbuch nicht gelesen hast.  
  
  
Freundliche Grüße  
  
Vinzenz

[Chris]

Hallo Vinzenz,

Woran liegt das? Ich kann es mir einfach nicht erklären.

Ich folgere daraus, dass Du das Handbuch nicht gelesen hast.

Da muss ich dir recht geben (leider). Ich habe über Google gesucht, aber nichts gefunden. An perldoc perlop hab ich nicht gedacht. Beim nächsten Mal denk ich dran, versprochen ;)

Trotzdem danke fürs Raussuchen. Es geht also doch, hätte mich auch sehr gewundert, wenn nicht.

Grüße
Chris

[steckl]

Hi,

In einem Formular wird eine E-Mail-Adresse eingetragen. Nun will ich einen simplen Check machen, ob die Adresse gültig ist oder nicht.
Falls sie es ist, speichere ich sie in %update_data, um sie später in die DB zu schreiben.

Die Funktion ist eigentlich egal, ich habe folgendes Code-Stück:
[...] param('email') =~ m/^\w+@\w+.\w+$/

Eine Anmerkung:
Damit filterst Du auch E-Mail-Adressen raus, die beispielsweise ein Minus enthalten. \w steht nur für Groß- und Kleinbuchstaben, Ziffern und Underscore.

mfG,
steckl

[Chris]

Eine Anmerkung:
Damit filterst Du auch E-Mail-Adressen raus, die beispielsweise ein Minus enthalten. \w steht nur für Groß- und Kleinbuchstaben, Ziffern und Underscore.

Danke für den Hinweis! Das habe ich mittlerweile auch mitbekommen :)
'.' hat auch gefehlt, aber das war mir klar, dass der Regex noch nicht fertig war.

grüße
chris

[steckl]

Hi,

Danke für den Hinweis! Das habe ich mittlerweile auch mitbekommen :)
'.' hat auch gefehlt, aber das war mir klar, dass der Regex noch nicht fertig war.

Ich wollte das auch mal machen und das Proglbem ist garnicht so banal. Falls es dich interessiert kannst hier mal reinschaun.

mfG,
steckl