PHP contra Perl



  • Optimizer schrieb:

    Ich sehe den Zusammenhang nicht.

    In beiden Fällen muss man wissen, was == bedeutet. Wenn man PHP programmiert, muss man halt wissen, dass Zeichenketten mit eq (oder was auch immer) verglichen werden und == eine andere Bedeutung hat, so wie du in C strcmp nehmen musst und es in C++ bei stringobjekten auf einmal doch wieder mit == geht.

    Vielleicht wird so ein "wischiwaschi-Vergleich" im Kontext der Webprogrammierung viel häufiger benötigt als der genaue Zeichenkettenvergleich.

    Ich kenne weder Perl noch PHP genauer aber nur weils ungewohnt erscheint, muss es ja nicht unlogisch sein.



  • Also, um nochmal hervorzuheben, was ich unlogisch finde:

    Ich finde es nicht unlogisch, dass wenn ich in C++ zwei Pointer vergleiche, dass nicht der Stringinhalt verglichen wird. Ich finde es nicht unlogisch, wenn bei std::string der Inhalt verglichen wird.

    Ich finde es unlogisch, wenn ich etwas dieser Form habe:
    einString == nochEinString

    dass beide Strings implizit in Zahlen konvertiert werden. Insbesondere, wenn es sich um Strings wie "sodiufh" handelt. DAS ist unlogisch. "dsuokfg" ist keine Zahl. Das ist auch nicht 0. 0 ist auch nicht das selbe wie "keine Zahl". Sowas gehört geschlagen.

    Du musst das Ganze jetzt noch unter dem Aspekt sehen, dass es so etwas wie Typen in PHP nicht direkt gibt. Du hast keine Möglichkeit, dich gegen so ein Verhalten zu wehren, weil _alles_ irgendwie in _alles_ umgewandelt wird. Ich finde es aber unlogisch, wenn ich links und rechts zwei gleiche Typen habe, dass beide umgewandelt werden. Weiter. Wenn also "soduhfölisgh" in 0 umgewandelt wird und mit der Zahl 0 verglichen true ergibt.
    Warum gibt dann eigentlich

    "sgdukf" == "skudgfkusgd"
    

    nicht

    0 == 0
    

    sondern liefert dann auf einmal false?

    Fragen über Fragen. Die man sicher irgendwo nachlesen kann. Aber das System ist Schrott. Es ist halt nirgendwo konsequent.

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.
    "10.0" == "000010" ➡ true

    und jetzt dafür wieder das. 🙄



  • Optimizer schrieb:

    Es ist halt nirgendwo konsequent.

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.
    "10.0" == "000010" ➡ true

    und jetzt dafür wieder das. 🙄

    also, wie gesagt, ich kenne PHP nicht, aber ich sehe hier schon konsequenz.
    So wie du bei "string" einen Pointer oder eine Zeichenkette siehst, sieht der ==-Operator eben einfach den Wert, also nicht die Repräsentation im Computer sondern eher das, was man auch als Mensch sieht.

    Woanders würde man sich dafür vielleicht eine Funktion human_compare(T, T) schreiben. Hier braucht man das jetzt offenbar so oft, dass es gleich ein Operator dafür gibt. Wieso nicht.



  • Was meinst du jetzt mit 'Wert' ? Den Wert als Zahl? Warum schlägt dann der Vergleich "abc" == "xyz" fehl? Weil das keine Zahlen sind? Warum trifft dann der Vergleich "abc" == 0 zu? Ne, das ist IMHO nicht konsequent.

    Und ich erwarte von einem op==, dass er transitiv ist. Sprich:

    Es sei x == y und y == z
    => x == z



  • Optimizer schrieb:

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.
    "10.0" == "000010" ➡ true

    und jetzt dafür wieder das. 🙄

    der Grund, warum das false liefert, ist weil der Inhalt von !abc" nicht gleich wie der von "xyz". Ich verstehe was du meinst, aber du solltest auch besser wissen, was php macht. PHP macht keine Typunwandlung rein willkürlich, sondern wenn es erfordelich ist. Wenn du "abc"=="cde" hast, dann weiß PHP, dass sowohl links als auch Rechts ein string steht und somit ist eine Typumwandlung überflüssig. Bei 0=="abc" ist es so, das PHP sieht, dass 0 ein int ist und abc ein string, so wandelt "abc" in ein int um, oder umgekehrt, das 0 in einem string. Die Typumwandlung erfolgt nur, wenn links und rechts ungleiche Typs stehen.

    Aber "abc"==$var1 ist tatsäclich riskant, deshalb bietet PHP Funktionen wie is_int, is_string, is_scalar,... und sollte davor benutzt werden.



  • supertux schrieb:

    Aber "abc"==$var1 ist tatsäclich riskant, deshalb bietet PHP Funktionen wie is_int, is_string, is_scalar,... und sollte davor benutzt werden.

    Ja, klar, das bringt das nicht-Typsystem sowieso mit sich. Deiner obigen Logik kann ich auch folgen. Ich habe nur folgendes Problem: Wenn ich deine Logik weiterspinne, komme ich zu diesem Fall:

    "10.0" == "000010"
    

    Ich möchte das jetzt unter deinem Gesichtspunkt betrachten:

    Wenn du "abc"=="cde" hast, dann weiß PHP, dass sowohl links als auch Rechts ein string steht und somit ist eine Typumwandlung überflüssig.
    

    Ich weiß jetzt, dass ich links und rechts einen String habe, denn ich habe ihn in schönen Anführungszeichen gesetzt. Trotzdem verhält sich PHP nicht so, wie es deiner (und meiner) Logik entspricht.

    Leider bist du auch nicht auf das Problem mit der Transitivität eingegangen. Der Operator == wird in der PHP Dokumentation als "Gleichheitsoperator" bezeichnet. "Gleichheit" ist, wie man weiß, in jeder beliebigen M (also Elementtyp beliebig!!) eine Äquivalenzrelation. Äquivalenzrelationen müssen folgende Bedingungen erfüllen:
    - Reflexivität
    - Symmetrie
    - Transitivität

    Und letzteres erfüllt der op== in PHP nicht. Diese Sprache ist damit mit der Logik (und ich rede hier nicht von meiner Logik, sondern der formal korrekten Logik) nicht greifbar. Und mich stört sowas, wenn ein op== keine Äquivalenzrelation ist.



  • oh Mann... wenn du eine Äquivlenzrelation haben willst, dann nim ein Baltt Papier und beweise die Übunsgaufgaben von Lineare Algebra 🙂
    Im Ernst, ich verstehe was du meinst, aber ich glaube nicht, dass die PHP Entwickler daran gedacht haben, dass es eine Äquivalenzrelation sein soll.

    Außerdem machst du einen Fehler. Auch bei Sprachen, die == als Äquivalenzrelation haben, liefert == einen greifbaren Wert zurück, wie TRUE/FALSE, 0 oder 1 oder was weiß ich. Eine richtige Äquivalenzrelation tut sowas nicht, weil sie eine Äquivrel. und keine Funktion ist. Aber ist == in keiner Sprache wirklich eine Äquivalenzrelation. Und du weißt, eine Äquivalrel. stellt Beziehungen zwischen Elementen einer Menge, bildet sie aber niergendswo ab.



  • Außerdem machst du einen Fehler. Auch bei Sprachen, die == als Äquivalenzrelation haben, liefert == einen greifbaren Wert zurück, wie TRUE/FALSE, 0 oder 1 oder was weiß ich. Eine richtige Äquivalenzrelation tut sowas nicht, weil sie eine Äquivrel. und keine Funktion ist.

    Hmmmm, kann ich nicht ganz nachvollziehen. In C++ ist == eine Äquivalenzrelation, außer du implementierst ihn für deine eigenen Typen falsch. In Java/C# auch.
    Und es ist ja keine Abbildung. Der Rückgabewert true oder false gibt ja nur an, ob die Aussage wahr oder falsch ist. Jede Relationale Aussage kann wahr oder falsch sein, ich würde das jetzt nicht als Funktion auffassen.

    Ich kann mir jetzt nirgendwo in besagten Sprachen einen Fall vorstellen, wo x == y und y == z wahre Aussagen sind, x == z dagegen falsch. In C++ ist es natürlich möglich, aber standardmäßig ist das Verhalten auch dort korrekt.

    Und wenn dir das Beispiel nicht zusagt, können wir ja wieder zu "10.0" == "000010" bzw. "sodosih" == "skudgf" wechseln. 😉
    Hier ist das Verhalten des Operators vom Wert der Operanden abhängig. Also ne Logik kann ich da nicht entdecken. 🙂



  • du hast mich nicht verstanden. Eine Äquivalenzrelation stellt nur die Bezihung zwischen Elementen einer Menge, wenn eine gegebene Bedingung gilt. == liefert in C/C++ einen Wert zurück, etwa 1 oder TRUE oder nenn ihn wie du es willst. Und das ist ein Unterschied, denn == ist eher eine Funktion (mathematisch gesehen) als eine Äquivalenzrelation (auch mathematische gesehen)


  • Mod

    Optimizer schrieb:

    "Gleichheit" ist, wie man weiß, in jeder beliebigen M (also Elementtyp beliebig!!) eine Äquivalenzrelation. Äquivalenzrelationen müssen folgende Bedingungen erfüllen:
    - Reflexivität
    - Symmetrie
    - Transitivität

    Und letzteres erfüllt der op== in PHP nicht.

    Du gehst von einer anderen Definition von Gleichheit als PHP aus.

    in PHP ist == nicht transitiv. Punkt. Sollte allgemeinhin bekannt sein, auch wenn die PHP Doku es nicht direkt erwaehnt.

    Du kannst jederzeit die Typen selber bestimmten (wozu kann man denn casten?)

    Das Problem das du mit PHP hast ist, dass es keine Typen gibt und zwar wirklich keine. "foo" ist eine string repraesentation des int wertes 0, wenn du so willst. Wenn du "-1"==-1 machst, bekommst du true, weil beides -1 darstellt. Bei "-foo"==-1 bekommst du false, weil "-foo" eben als int repraesentation 0 hat.

    Das ist kein bisschen unlogisch, sondern einfach nur anders als bei Sprachen wie Java oder C++.

    Wenn du wirklich 2 strings vergleichen willst, nimm strcmp oder mach strval auf beide operanden. Um so die repraesentation so zu deiner zufriedenheit anzupassen.

    PHP hat diesen Schritt bewusst gewaehlt, weil es die beste Loesung fuer das Problem ist -> wie willst du 2 unterschiedliche Typen vergleichen?
    Entweder ist
    "0" != 0.0
    oder
    0 == "foo"

    fuer eins musst du dich entscheiden.

    oder du machst es wie perl und erfindest eq und ==
    PHP hat beide wege gewaehlt
    "0"==0.0
    und
    strcmp(0,"foo")==0

    cool, gell?

    das ist keineswegs unlogisch, lediglich anders als bei anderen sprachen.

    in der praxis stoert das nicht transitive verhalten von == aber kein bisschen.

    [quote[Diese Sprache ist damit mit der Logik (und ich rede hier nicht von meiner Logik, sondern der formal korrekten Logik) nicht greifbar.[/quote]
    Was natuerlich nicht stimmt. Weil du von falschen voraussetzungen ausgehst.

    Und mich stört sowas, wenn ein op== keine Äquivalenzrelation ist.

    Mich nicht, und?



  • Shade Of Mine schrieb:

    Du gehst von einer anderen Definition von Gleichheit als PHP aus.

    Das ist doch keine Aussage. Du gehst von einer anderen Definition von "Blau" aus als ich. Gleichheit ist eine mathematisch definierte Äquivalenzrelation und ich kenne sonst keine Sprache, die das verletzt. Ich bring doch den mathematischen Schnickschnack nicht zum Spaß. Während ich hier eine allgemein akzeptierte Grundlage bringe sagst du einfach "PHP definiert es anders". Nicht nur das. Du sagst "Ich definiere es anders als PHP".

    Das Problem das du mit PHP hast ist, dass es keine Typen gibt und zwar wirklich keine. "foo" ist eine string repraesentation des int wertes 0, wenn du so willst. Wenn du "-1"==-1 machst, bekommst du true, weil beides -1 darstellt. Bei "-foo"==-1 bekommst du false, weil "-foo" eben als int repraesentation 0 hat.

    Das ist kein bisschen unlogisch, sondern einfach nur anders als bei Sprachen wie Java oder C++.

    Nimm mich bitte ein bisschen wörtlicher. Ich hab nicht gesagt, dass ich das unlogisch finde. Ich habe gesagt, dass ich es unlogisch finde, dass der op== sich je nach Wert der Operanden anders umwandelt und vergleicht:

    "foo" ist eine string repraesentation des int wertes 0

    und "bar" auch, oder? Fein, kann ich mit leben. Trotzdem fällt der Vergleich "foo" == "bar" negativ aus. Und das ist unlogisch. Nicht das, was du mir oben ankreiden willst, so intolerant bin ich auch wieder nicht. 😉 Es fehlt einfach die Konsequenz.

    Wenn du wirklich 2 strings vergleichen willst, nimm strcmp oder mach strval auf beide operanden. Um so die repraesentation so zu deiner zufriedenheit anzupassen.

    Das Vergleichen von Strings ist jetzt nicht mein Problem...

    PHP hat diesen Schritt bewusst gewaehlt, weil es die beste Loesung fuer das Problem ist -> wie willst du 2 unterschiedliche Typen vergleichen?
    Entweder ist
    "0" != 0.0
    oder
    0 == "foo"

    fuer eins musst du dich entscheiden.

    Kann ich nicht nachvollziehen. Ich sehe keine Notwendigkeit "foo" den numerischen Wert 0 zu verpassen. Man hätte den Vergleich 0 == "bar" besser einfach negativ ausfallen lassen sollen und von mir aus 0 == "0" positiv. Aber etwas, was offenkundig keine Zahl ist, einfach den Wert 0 zu verpassen, finde ich reichlich seltsam. Falls ich jetzt einfach grad nur nicht mitkomme, dann erklär mir doch bitte etwas ausführlicher, warum das nötig/praktikabel ist. 🙂

    Diese Sprache ist damit mit der Logik (und ich rede hier nicht von meiner Logik, sondern der formal korrekten Logik) nicht greifbar.

    Was natuerlich nicht stimmt. Weil du von falschen voraussetzungen ausgehst.

    Wieso? Ich bin von der Dokumentation ausgegangen, die etwas mit "Gleichheit" verspricht. Also bin ich von Gleichheit ausgegangen und das ist definiert. Dabei spielt es keine Rolle, wie die Prüfung in der Praxis durchgeführt wird. Ob wie in Java Referenzen verglichen werden (was ja eigentlich eine Identitäsprüfung ist, aber genauso transitiv), wie bei std::string der Inhalt oder ob es überhaupt keine Typen gibt wie in PHP spielt dabei keine Rolle. Der Begriff Gleichheit ist viel abstrakter definiert und beschreibt nur das Verhalten der Relationen. Und wie gesagt, ich habe noch nirgendwo gesehen, dass das verletzt wird.

    Und mich stört sowas, wenn ein op== keine Äquivalenzrelation ist.

    Mich nicht, und?

    Nichts und. Das ist doch sehr schön, dass es dich nicht stört. 🙂
    Trotzdem darf ich ja wohl sagen, dass es mich schon stört.



  • Optimizer schrieb:

    Gleichheit ist eine mathematisch definierte Äquivalenzrelation und ich kenne sonst keine Sprache, die das verletzt.

    in C++ ergibt "Hallo" == "Hallo" && "Hallo" == "Hallo" auch nicht zwingend true.
    In PHP ist einfach das abstraktionslevel höher. Der Variablen-Typ ist uninteressant.
    Also 10 == 10.0 == "0010" == "zehn". Jenachdem wie mans interpretiert.

    In anderen Sprachen baut man sich das uU. mit wilden Verrenkungen nach.



  • DrGreenthumb schrieb:

    Optimizer schrieb:

    Gleichheit ist eine mathematisch definierte Äquivalenzrelation und ich kenne sonst keine Sprache, die das verletzt.

    in C++ ergibt "Hallo" == "Hallo" && "Hallo" == "Hallo" auch nicht zwingend true.
    In PHP ist einfach das abstraktionslevel höher. Der Variablen-Typ ist uninteressant.
    Also 10 == 10.0 == "0010" == "zehn". Jenachdem wie mans interpretiert.

    In anderen Sprachen baut man sich das uU. mit wilden Verrenkungen nach.

    Da wirfst du aber gerade zwei Dinge zusammen. Um es gleich vorweg zu nehmen: Ich bin schon die ganze Zeit auf der höchstmöglichen Abstraktionsebene. 😉 Der Typ interessiert mich auch nicht.

    In deinem C++ Beispiel vergleichst du nicht die Strings. Mehr gibt es dazu nicht zu sagen. Sei a, b, c vom Typ const char*:

    a == b und b == c ➡ a == c
    Das ist auch in C++ so. Wenn die Adressen jeweils gleich sind hat auch a und c die selbe Adresse.
    Deine ganzen "Hallo"s müssen aber nicht die selbe Adresse haben. Wie du Gleichheit feststellst ist völlig egal, es muss nur die Transitivität stimmen und das tut sie, wenn
    - std::strings vergleichst
    - const char* vergleichst

    Bei deinem "Hallo" kennst du aber die Adresse (also den Wert, den du vergleichst) gar nicht also kannst du schlecht ne Aussage machen. 😉



  • Optimizer schrieb:

    a == b und b == c ➡ a == c
    Das ist auch in C++ so.

    in PHP nicht? Anhand der PHP-Kenntnisse die ich in diesem Thread gewonnen habe, sehe ich kein problem.

    "abc" == 0 ➡ true
    "xyz" == 0 ➡ true
    "abc" == "xyz" ➡ false
    macht schon keinen Sinn mehr. Der Vergleichsoperator ist damit nicht transitiv.

    kannst du diese Variablen in dein Beispiel einsetzen?



  • Ja:

    "abc" == 0 und 0 == "xyz" ➡ "abc" == "xyz"

    Die Folgerung funktioniert aber in PHP nicht, liefert also false, obwohl die beiden Vorausetzungen true geliefert haben. Dass der op== in PHP sich nicht transitiv verhält, bestreitet ja Shade auch nicht. Ihn stört es nur nicht, mich halt schon. Das heißt natürlich nicht, dass ich für "abc" == "xyz" true haben will, sondern mich stört natürlich das ... == 0.

    Aber egal, das hab ich ja jetzt gesagt und das darf jeder finden wie er will. 🙂



  • Optimizer schrieb:

    "abc" == 0 und 0 == "xyz" ➡ "abc" == "xyz"

    jetzt seh ichs 😉

    aber dennoch, kein kriterium für oder gegen die Sprache. Es liegt an der Anwendung, ob == oder sonst ein Vergleichsoperator aufgerufen wird.

    Das ist nur Syntax.


  • Mod

    Optimizer schrieb:

    Kann ich nicht nachvollziehen. Ich sehe keine Notwendigkeit "foo" den numerischen Wert 0 zu verpassen. Man hätte den Vergleich 0 == "bar" besser einfach negativ ausfallen lassen sollen und von mir aus 0 == "0" positiv.

    Welchen int wert sollte bar denn deiner meinung nach haben?
    Man koennte natuerlich nan einfuehren, aber das haette wiederum die komplexitaet erhoeht. denn dann waere ein
    foo=intval(foo=intval(var);
    nicht mehr moeglich, dann wuerde das uU nan liefern und wir muessten es als
    foo=intval(foo=intval(var); if($foo==nan) $foo=0;
    schreiben.

    waere irgendwie doof.

    dass intval("foo") zu 0 wird ist auch praktisch, weil 0 eine legale zahl ist und idR einen guten defaultwert abgibt. wenn man das nicht will, kann man immer noch mit is_numeric(var)?intval(var) ? intval(var) : $defaultwert; arbeiten.

    0 ist per definition in PHP etwas ungueltiges -> leeres. Das erkennt man zB an
    v=0;empty(v=0; empty(v)==true;

    wir koennen uns natuerlich streiten ob nan hier vielleicht besser waere. das mag sein, mag aber vielleicht auch nicht sein. denn nan bringt eben das problem einer undefinierten zahl mit sich, sowas kann laestig sein.

    die transitivitaet wurde bewusst aufgegeben um dem programmierer etwas bequemlichkeit zu schenken.

    fuer die wenigen faelle wo das eine rolle spielt, gibt es den op=== mit expliziten casten -> strval(a)===strval(a)===strval(b)

    Wieso? Ich bin von der Dokumentation ausgegangen, die etwas mit "Gleichheit" verspricht. Also bin ich von Gleichheit ausgegangen und das ist definiert. Dabei spielt es keine Rolle, wie die Prüfung in der Praxis durchgeführt wird.

    Dann nenne es meinetwegen einen Bug in der Doku

    Der Begriff Gleichheit ist viel abstrakter definiert und beschreibt nur das Verhalten der Relationen. Und wie gesagt, ich habe noch nirgendwo gesehen, dass das verletzt wird.

    Oh, ist ganz einfach das zu verletzen: man nehme einen case insensitiven string der von einem sensitiven erbt.

    schont hat man
    insensitiv ins="hallo";
    sensitiv sen="Hallo";
    sensitiv sen2="hallO";
    ins==sen
    ins==sen2
    sen!=sen2

    hier haengt man also auch schon an diesem problem... laesst sich natuerlich loesen, keine frage.

    Das Problem das man hat: der wert einer variablen haengt vom kontext ab. Und ein ungueltiger int wert wird oft als 0 angenommen -> zB in VB oder auch bei der C Funktion atoi()

    Trotzdem darf ich ja wohl sagen, dass es mich schon stört.

    natuerlich darfst du es sagen. aber in PHP ist es halt so definiert, dass sich der wert einer variablen von kontext zu kontext unterscheiden kann.
    wenn intval("foo") == NAN waere, dann haettest du folgendes problem:
    NAN == "foo"
    NAN == "bar"
    "foo" != "bar"

    in PHP ist der op== halt so definiert:
    (is_numeric(a) && is\_numeric(b)) || (is_int(a)is_int(a) || is\_int(b)) ? intval(a)===intval(a)===intval(b) : a===a===b;

    aber bei einem gebe ich dir recht: es koennte in der doku ruhig etwas expliziter dort stehen.

    tatsache ist aber: mir ist es noch nie passiert, dass ich wegen der nicht transitivitaet einen bug oder sonstige probleme hatte oder je gesehen habe.

    andererseits habe ich aber schon oft von einem intval("foo) == 0 oder 0=="foo" profitiert.

    Edit:
    Falls du unterschrieben haben willst, dass PHP unschoen ist -> mache ich sofort.
    Allerdings sind viele dieser unschoenheiten verdammt oft verdammt praktisch...



  • Shade Of Mine schrieb:

    Welchen int wert sollte bar denn deiner meinung nach haben?
    Man koennte natuerlich nan einfuehren, aber das haette wiederum die komplexitaet erhoeht. denn dann waere ein
    foo=intval(foo=intval(var);
    nicht mehr moeglich, dann wuerde das uU nan liefern und wir muessten es als
    foo=intval(foo=intval(var); if($foo==nan) $foo=0;
    schreiben.

    waere irgendwie doof.

    Ich würds ja eigentlich besser finden, wenn die zahl in einen string gecastet würde. Das wäre zumindest immer möglich. Macht man wahrscheinlich aber nicht so oft, wie umgekehrt und anscheined soll beim PHP programmieren alles ohne Zutun des Programmierers geschehen.

    0 ist per definition in PHP etwas ungueltiges -> leeres. Das erkennt man zB an
    v=0;empty(v=0; empty(v)==true;

    0 ist mir in PHP (wie auch in C++, nur dort nicht ganz so schlimm) zu viele Sachen.

    Doku (sinngemäß) schrieb:

    strpos liefert FALSE, falls der Teilstring nicht gefunden wird.

    Wir haben jetzt also:
    "nicht gefunden" == FALSE == 0 == "an der Stelle 0 gefunden". 😮
    Und so läuft es dann auch. Wenn du am Anfang des Strings deinen Teilstring findest, kriegste FALSE. Jetzt kann man natürlich streiten, ob es nicht doch an strpos liegt und nicht an PHP.

    Letztlich ist die Ursache für die meisten Unschönheiten IMHO das Typsystem. Da wurde schon einiges mehr als die Transitivität von == aufgegeben, um mit dem nicht-Typsystem vernünftig arbeiten zu können. Und was ist der Gewinn? Ich sehe keinen. Vielleicht ist es für die Script-Kiddies ein Gewinn, ich weiß es nicht.

    Mich würde mal interessieren, ob das in Perl ein bisschen besser gelöst ist. Vielleicht schau ich mir das doch mal an.

    Oh, ist ganz einfach das zu verletzen: man nehme einen case insensitiven string der von einem sensitiven erbt.

    Ehrlich gesagt finde ich das eine etwas seltsame Vererbungsbeziehung.
    Wie auch immer, ich bestreite ja nicht, dass du mit C++ oder C# einen "komischen" op== bauen kannst. Spätestens mit return rand()%2 == 0 wird dir das schon gelingen. Aber standardmäßig werden solche Regeln keinesfalls verletzt und ich kann mir auch nicht vorstellen, dass du mal in eine so blöde Situation kommst, dass du das willst.

    Das Problem das man hat: der wert einer variablen haengt vom kontext ab. Und ein ungueltiger int wert wird oft als 0 angenommen -> zB in VB oder auch bei der C Funktion atoi()

    Das ist genau das, was man beim Design moderner Programmiersprachen und Bibliotheken vermeidet. Wobei modern relativ ist, eigentlich vermeidet man so etwas schon seit C++... ich frage mich, ob das einen Grund hat? 😉

    Allerdings sind viele dieser unschoenheiten verdammt oft verdammt praktisch...

    Es ist halt nicht meins. Dafür bin ich zu idealistisch. 🙂



  • Optimizer schrieb:

    Ja:

    "abc" == 0 und 0 == "xyz" ➡ "abc" == "xyz"

    Die Folgerung funktioniert aber in PHP nicht, liefert also false, obwohl die beiden Vorausetzungen true geliefert haben. Dass der op== in PHP sich nicht transitiv verhält, bestreitet ja Shade auch nicht. Ihn stört es nur nicht, mich halt schon. Das heißt natürlich nicht, dass ich für "abc" == "xyz" true haben will, sondern mich stört natürlich das ... == 0.

    Aber egal, das hab ich ja jetzt gesagt und das darf jeder finden wie er will. 🙂

    wenn du schon mit Äquivalenzrelationen argumentierst, dann sollest du auch konsistenz bleiben. Mathematisch gesehen muss das auch nicht gelten, weil "abc" und 0 in 2 unterschiedlichen Mengen liegen, somit ist nicht eindeutig definiert, ob "abc" == "xyz". Wären "abc" und 0 (und "xyz" und 0) in der geleichen Menge, dann würde "abc"=="xyz" gelten. Also wäre == sehr wohl transitiv.

    PHP geht ein Stückchen im vor und wenn er merkt, dass "xyz" und 0 nicht in der gleichen Menge liegen, dann gibt es eine Typumwandlung. Somit ist die Folgerung "xyz"=="abc" nicht notwendig zu erfüllen.

    "abc" == 0 und 0 == "xyz" ➡ (int) "abc" == (int) "xyz"

    gilt, PHP wandelt "abc" und "xyz" in ints, sie sind nach PHP Definitionen 0 und somit ist == transitiv, sobald alle Operanden (links und rechts) sich in der gleichen Menge befinden.

    Kann ich nicht nachvollziehen. Ich sehe keine Notwendigkeit "foo" den numerischen Wert 0 zu verpassen. Man hätte den Vergleich 0 == "bar" besser einfach negativ ausfallen lassen sollen und von mir aus 0 == "0" positiv.

    Kannst du nicht akzeptieren, dass es andere Sprachen gibt, die andere Ansätze haben als deine? In PHP ist es jedenfalls so und wer mit PHP arbeitet soll damit leben, sonst eine andere Sprache wählen.



  • PHP geht ein Stückchen im vor und wenn er merkt, dass "xyz" und 0 nicht in der gleichen Menge liegen, dann gibt es eine Typumwandlung. Somit ist die Folgerung "xyz"=="abc" nicht notwendig zu erfüllen.

    Das stimmt jetzt nicht, denn 0 und "xyz" liegen in der selben Menge, amsonsten könntest du den Vergleich gar nicht durchführen. Der Begriff "Typumwandlung" existiert im mathematischen Sinne so nicht und in PHP ist er auch mit Vorsicht zu genießen.
    Wenn ich "abc" mit 0 vergleichen kann und "xyz" mit 0, dann muss ich auch "abc" mit "xyz" vergleichen können, sonst kann es ja allein schon keine Äquivalenzrelation sein. Du dagegen folgerst einfach mal daraus, dass, weil es nicht vergleichbar ist, die Folgerung einfach nicht zu erfüllen ist. Nene. Das ist erst schon mal grundlegende Voraussetzung für eine Äquivalenzrelation.

    Kannst du nicht akzeptieren, dass es andere Sprachen gibt, die andere Ansätze haben als deine? In PHP ist es jedenfalls so und wer mit PHP arbeitet soll damit leben, sonst eine andere Sprache wählen.

    Wo ist denn dein Problem? Ich habe gesagt, was mich an PHP stört und dafür muss ich mich jetzt seit 3 Seiten bis ins Detail rechtfertigen. Ich muss sogar erstmal mathematisch begründen, was ich von einem Gleichheitszeichen erwarte, obwohl man woanders nirgendwo etwas anderes erwarten würde. Und diese Erwartung wird hier nicht erfüllt und das stört mich. Mehr habe ich nicht gesagt.
    Und das mit "andere Sprache wählen" ist evtl. nicht so leicht. Vielleicht kennst du nen kostenlosen JSP-Server?


Anmelden zum Antworten