Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Skriptsprachen: PHP 5.5…

Schöner wäre mal eine zumindest optionale Typensicherheit...

  1. Thema

Neues Thema Ansicht wechseln


  1. Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: Vanger 19.11.12 - 13:26

    Das wäre doch mal was... Das würde dann auch direkt einen Großteil der Dinge, die in PHP absolut lächerlich realisiert, vollkommen absurd und einfach nur nervig sind, in die ewigen Jagdgründe schicken. Dazu dann bitte noch einheitliche Klassen zur Manipulation der Datentypen - denn jedes mal in der Doku den Funktionsnamen und die von Funktion zu Funktion andere Parameterreihenfolge nachschlagen zu müssen nervt einfach nur. Schließlich noch einheitlich alle Fehler-Rückgabewerte (meist null oder false) gegen Exceptions austauschen... Alte Features wie das mysql- und mysqli-Modul entfernen... C-Wrapper sinnvoll integrieren (so ein Schwachsinn wie *_get_last_error() darf es einfach nicht geben)... Ja dann hätten wir doch mal was geschafft.

    Denn auch wenn
    > http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
    von jemandem gesammelt wurde der nie wirklich etwas mit PHP geschrieben hat und in seiner Einleitung direkt klar werden lässt, dass er nicht mehr als ein Troll ist (Python-Fanboy), hat er bei einigen Punkten schlicht und ergreifend recht.

  2. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: tomate.salat.inc 19.11.12 - 13:38

    +1

  3. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: Polecat42 19.11.12 - 14:49

    optionale Typensicherheit? Exakt das gibt's doch schon? Für Objekte seit 5.2 afaik, und für primitives seit 5.4... zumindest in Funktionsdeklarationen.

    Bei simplen Zuweisungen und Operationen bin ich vor allem im Web-Kontext froh, dass ich *nicht* jeden Murks erst umwandeln muss. Was sollte auch gegen

    $age = 42;
    'I am ' . $age . ' years old';

    sprechen...

    Aber ansonsten: ja, diese resource und handler-Geschichten sind echt grauenhaft... curl z.B. ganz vorne mit dabei...

  4. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: developer 19.11.12 - 15:31

    Vanger schrieb:
    --------------------------------------------------------------------------------
    > Das wäre doch mal was... Das würde dann auch direkt einen Großteil der
    > Dinge, die in PHP absolut lächerlich realisiert, vollkommen absurd und
    > einfach nur nervig sind, in die ewigen Jagdgründe schicken.

    Ja es ist echt frustrierend, dass scalar typehinting wieder raus geworfen wurde weil man sich scheins nicht drauf einigen konnte welchen Effekt die hints haben sollten.

    > Dazu dann bitte
    > noch einheitliche Klassen zur Manipulation der Datentypen - denn jedes mal
    > in der Doku den Funktionsnamen und die von Funktion zu Funktion andere
    > Parameterreihenfolge nachschlagen zu müssen nervt einfach nur.

    Ja wäre schön und wünschenswert, würde aber nen ziemlichen cut bei der Abwärtskompatibilität für ältere Scripte geben.

    > Schließlich noch einheitlich alle Fehler-Rückgabewerte (meist null oder false) gegen
    > Exceptions austauschen...

    Siehe Abwärtskompatibilität. Frusrtierend, aber der shitstorm wäre vermutlich episch wenn man bedenkt welche Gruppe von Nutzern da hauptsächlich betroffen wäre.

    > Alte Features wie das mysql- und mysqli-Modul
    > entfernen... C-Wrapper sinnvoll integrieren (so ein Schwachsinn wie
    > *_get_last_error() darf es einfach nicht geben)...

    Korrekt aber auch hier wieder Abwärtskompatibilität.
    Wenn plötzlich ungefangene Exceptions geworfen werden hast du keinen Spaß mehr vor lauter bösen Kommentaren von Menschen die glauben sie würden PHP schreiben. Weißt ja je mehr Ahnung durch Meinung ersetzt wird desto lauter wird selbige verbreitet.

    > Ja dann hätten wir doch mal was geschafft.
    >

    Wenn es doch nur so einfach wäre.

    > Denn auch wenn
    > > me.veekun.com
    > von jemandem gesammelt wurde der nie wirklich etwas mit PHP geschrieben hat
    > und in seiner Einleitung direkt klar werden lässt, dass er nicht mehr als
    > ein Troll ist (Python-Fanboy), hat er bei einigen Punkten schlicht und
    > ergreifend recht.

    Teils hat er Recht, teils keine Ahnung.
    Das sind mittlerweile eher "politische" als technischer Probleme.

    Fakt ist aber, dass man die meisten Probleme durch den Einsatz eines guten Frameworks beheben kann ( nicht alle schon klar ), dass die unschönen und architektonisch fragwürdigen Stellen wegabstrahiert, und eine sauberes und Exception Management + konsistente Interfaces bereitstellen kann.

    Ja, dann kommt wieder die Fraktion die sagt bei anderen Sprachen wäre der Core ja so sauber da müsste man das nicht mit nem fetten Framework fixen, aber wenn man genauer hinschaut gibts in den Sprachen auch populäre Frameworks die eine ähnliche Abstraktion bereit stellen wie das bei PHP Frameworks der Fall ist.

    Somit treten viele der propagierten Probleme in der Praxis gar nicht erst auf wenn man weiß was man macht.

    Zugegeben gerade letzteres ist bei der Sprache oft nicht der Fall, aber das gibts bei anderen populären Sprachen auch.

  5. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: Vanger 19.11.12 - 15:47

    > Für Objekte seit 5.2 afaik
    Schon seit PHP 5.1.

    > für primitives seit 5.4... zumindest in Funktionsdeklarationen.
    Das wäre mir neu. Seit PHP 5.4 gibt es zusätzlich zu den Objekt-/Interface- und Array-Typehints zusätzlich noch den callable-Typehint, sonst aber auch nichts. Es ist nicht möglich als Funktionsparameter einen bestimmten primitiven Datentyp (String, Integer, Float, Boolean) vorauszusetzen.

    > Bei simplen Zuweisungen und Operationen bin ich vor allem im Web-Kontext
    > froh, dass ich *nicht* jeden Murks erst umwandeln muss.
    Wenn Typensicherheit implementiert wird, ist es kein großer Schritt eine gewisse Abstufung der Typensicherheit zu implementieren - dass man den Programmierer entscheiden lässt welche automatische Umwandlungen/Type Castings zulässig sind und welche nicht. Denn du hast Recht, es gibt einige Umwandlungsformen die einem das Leben eher erleichtern, andere aber machen es einem sehr sehr viel schwerer.

    Ich persönlich würde beispielsweise nur die automatische Umwandlung von Integern und Floats zu Strings erlauben - wie auch von Objekten zu Strings, aber nur wenn die __toString()-Methode implementiert wurde. Sinnvoll ist vermutlich auch die automatische Umwandlung von Integern zu Floats. Persönlich lehne ich die Umwandlung von Integern zu Boolean ab, insbesondere weil ich sie verwirrend finde: in der Unix-Welt bedeutet der Rückgabewert "0" Erfolg, "Nicht-0" hingegen den Fehlerfall. Bei der Umwandlung ist es aber umgekehrt. Deswegen lehne ich auch if(count($a)) ab und verwende ausschließlich if(count($a) !== 0).

    Was in meinen Augen wirklich überhaupt gar nicht geht ist einen String in irgendetwas umwandeln zu wollen...

  6. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: Vanger 19.11.12 - 16:07

    > > Das wäre doch mal was... Das würde dann auch direkt einen Großteil der
    > > Dinge, die in PHP absolut lächerlich realisiert, vollkommen absurd und
    > > einfach nur nervig sind, in die ewigen Jagdgründe schicken.
    > Ja es ist echt frustrierend, dass scalar typehinting wieder raus geworfen
    > wurde weil man sich scheins nicht drauf einigen konnte welchen Effekt die
    > hints haben sollten.
    Wie jetzt - das war schon umgesetzt und wurde wieder rausgeworfen? Oh my god...

    > > Dazu dann bitte
    > > noch einheitliche Klassen zur Manipulation der Datentypen - denn jedes
    > mal
    > > in der Doku den Funktionsnamen und die von Funktion zu Funktion andere
    > > Parameterreihenfolge nachschlagen zu müssen nervt einfach nur.
    > Ja wäre schön und wünschenswert, würde aber nen ziemlichen cut bei der
    > Abwärtskompatibilität für ältere Scripte geben.
    Die Klassen wären ja erstmal nur zusätzlich, es wäre ja durchaus möglich die alten Funktionen vorerst zu behalten. So wird das ja auch jetzt schon behandelt, alte Features bleiben vorerst bestehen und werden erst Jahre später tatsächlich entfernt. Letztlich implementiert man die alten Funktionen einfach als Alias zu den entsprechenden neuen Klassenmethoden und wirft ein E_DEPRECATED.

    > > Schließlich noch einheitlich alle Fehler-Rückgabewerte (meist null oder
    > false) gegen
    > > Exceptions austauschen...
    > Siehe Abwärtskompatibilität. Frusrtierend, aber der shitstorm wäre
    > vermutlich episch wenn man bedenkt welche Gruppe von Nutzern da
    > hauptsächlich betroffen wäre.
    Für die E_*-Fehlerfälle entstünden vermutlich keine wirklichen Probleme, es wird eben statt einem nicht fangbaren E_*-Fehler eine fangbare Exception geworfen. Wie bisher könnte man das Werfen einer Exception verhindern indem man den @-Operator voranstellt. Um null/false-Rückgabewerte zu ersetzen hat man größere Probleme. Ich würde die Rückgabewerte in einer Übergangszeit einfach noch behalten und das werfen von Exceptions über eine Option steuern. Bei jemandem der die Exceptions dann aktiviert hat würde der Rückgabewert ja eh nie geliefert werden.

    > > Alte Features wie das mysql- und mysqli-Modul
    > > entfernen... C-Wrapper sinnvoll integrieren (so ein Schwachsinn wie
    > > *_get_last_error() darf es einfach nicht geben)...
    > Korrekt aber auch hier wieder Abwärtskompatibilität.
    Zumindest bei der *_get_last_error()-Thematik denke ich nicht, dass das bei vielen wirklich ein Problem darstellen wird: Die nackten C-Wrapper werden nicht exzessiv genutzt und wenn dann werden die *_get_last_error()-Funktionen gar nicht verwendet. Die wirklich betroffene Gruppe der Entwickler wird recht klein sein.

    Ansonsten gilt das gleiche wie beim vorherigen Punkt: Macht man's halt einfach von ner Option abhängig und bietet die alten *_get_last_error()-Funktionen weiterhin an - auch wenn sie dann redundante Informationen liefern.



    Grundsätzlich zur Thematik Abwärtskompatibilität: Ich finde es merkwürdig, dass in der Doku noch so intensiv mit eigentlich veraltetem Verhalten gearbeitet wird. Veraltetes Verhalten, wie dann beispielsweise null/false-Rückgabewerte oder alte Funktionen zur Manipulation von Datentypen, sollten aus der "normalen" Doku gleich komplett verschwinden und nirgends mehr erwähnt werden. Für ältere PHP-Versionen soll es dann einfach eine separate Doku geben die mit dem Release der neuen PHP-Version eingefroren wird.

    Das würde auch das Problem lösen wenn man noch für die jeweils ältere Version kompatibel programmieren will. Da PHP 5.4 bei vielen Hostern noch nicht angekommen ist, entwickeln viele schlicht noch auf dem Stand von PHP 5.3. Dagegen spricht erstmal auch nichts. Nervig ist nur, dass die Doku hier nicht unterscheidet...

  7. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: crash 19.11.12 - 16:57

    Scalar Type Hinting wurden diskutiert. Eine Implementation war nie fertig.

    Siehe: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html

    (am besten du ließt es erst gar nicht, ist zum Kopfschütteln :)

  8. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: crash 19.11.12 - 17:20

    Achja, ein Proposal für 5.5: https://wiki.php.net/rfc/scalar_type_hinting_with_cast

  9. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: developer 19.11.12 - 20:16

    > (am besten du ließt es erst gar nicht, ist zum Kopfschütteln :)

    Japp auf den Artikel hatte ich mich gedanklich bezogen, nur verlinken wollte ich den aus von dir angeführten Gründen lieber nicht.

  10. Re: Schöner wäre mal eine zumindest optionale Typensicherheit...

    Autor: developer 19.11.12 - 20:22

    Im interesser der lesbarkeit lass ich das mal mit dem zitieren.
    In den meisten Punkten geb ich dir Recht.
    Mit Aliases + E_DEPRECATED könnte man da einiges lösen und wirklich aufwendig erscheint mir das gerade auch nicht.

    Zu der Doku muss man sagen sie hat ihre Stärken und Schwächen, da gibt sicher einiges das man aktualisieren sollte.
    Schlimmer find ich aber, dass warum auch immer gerade die Menschen die das NICHT machen sollten weil sie überhaupt kein Plan von PHP haben fleisig dabei sind das Web mit teils schon höchst fragwürdigen meist auch noch gefährlichen Tutorials zu fluten.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Stadt Lippstadt, Lippstadt
  2. inovex GmbH, verschiedene Einsatzorte
  3. PHOENIX group IT GmbH, Fürth
  4. CGM Mobile GmbH, Koblenz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (nur für Prime-Kunden)
  2. (nur für Prime-Kunden)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Leistungsschutzrecht/Uploadfilter: Worüber das Europaparlament wirklich abstimmt
Leistungsschutzrecht/Uploadfilter
Worüber das Europaparlament wirklich abstimmt

Das Europaparlament entscheidet am Donnerstag über das Leistungsschutzrecht und Uploadfilter. Doch Gegner und Befürworter streiten bis zuletzt, worüber eigentlich abgestimmt wird. Golem.de analysiert die Vorschläge.
Eine Analyse von Friedhelm Greis

  1. Urheberrecht Europaparlament bremst Leistungsschutzrecht und Uploadfilter
  2. Urheberrecht Freies Netz für freie Bürger
  3. Leistungsschutzrecht Verleger attackieren Bär und Jarzombek scharf

Youtube Music, Deezer und Amazon Music: Musikstreaming buchen ist auf dem iPhone teurer
Youtube Music, Deezer und Amazon Music
Musikstreaming buchen ist auf dem iPhone teurer

Wer seinen Musikstreamingdienst auf einem iPhone oder iPad bucht, muss oftmals mehr bezahlen als andere Kunden. Der Grund liegt darin, dass Apple - außer bei eigenen Diensten - einen Aufschlag von 30 Prozent behält. Spotify hat Konsequenzen gezogen.
Ein Bericht von Ingo Pakalski

  1. Filme und Serien Nutzung von kostenpflichtigem Streaming steigt stark an
  2. Highend-PC-Streaming Man kann sogar die Grafikkarte deaktivieren
  3. Golem.de-Livestream Halbgott oder Despot?

Garmin Fenix 5 Plus im Test: Mit Musik ins unbekannte Land
Garmin Fenix 5 Plus im Test
Mit Musik ins unbekannte Land

Kopfhörer ins Ohr und ab zum Joggen, Rad fahren oder zum nächsten Supermarkt spazieren - ohne Smartphone: Mit der Sport-Smartwatch Fenix 5 Plus von Garmin geht das. Beim Test haben wir uns zwar im Wegfindungsmodus verlaufen, sind von den sonstigen Navigationsoptionen aber begeistert.
Ein Test von Peter Steinlechner

  1. Garmin im Hands on Alle Fenix 5 Plus bieten Musik und Offlinenavigation

  1. Battlefield 5: Mehr Reaktionsmöglichkeiten statt schwächerer Munition
    Battlefield 5
    Mehr Reaktionsmöglichkeiten statt schwächerer Munition

    Nach dem Alphatest zieht Dice öffentlich Bilanz: Neben dem Matchmaking und einigen technischen Details soll es bei Battlefield 5 Änderungen bei der Anzeige von Treffern geben. Wie sich das dann spielt, dürfen Spieler auf der Gamescom 2018 ausprobieren.

  2. Gesichtserkennung: Minority Report soll für Microsoft nicht real werden
    Gesichtserkennung
    Minority Report soll für Microsoft nicht real werden

    1984 und Minority Report sind mittlerweile fast reale Szenarien. Dieser Meinung ist Microsoft-Präsident Brad Smith. Er stellt Fragen, wie Gesichtserkennung sinnvoll und ohne Rechtsverletzungen genutzt werden kann - und zeigt mit dem Finger auf Amazon und Google.

  3. Google Assistant: Googles smarter Lautsprecher kann Termine anlegen
    Google Assistant
    Googles smarter Lautsprecher kann Termine anlegen

    Mit einem Google-Assistant-Lautsprecher lassen sich auf Zuruf neue Termine anlegen. Damit wird der smarte Lautsprecher nützlicher. Als weitere Neuerung spielen Google-Assistant-Lautsprecher Musik auch im Flac-Format ab - aber nur, wenn Deezer verwendet wird.


  1. 11:05

  2. 10:42

  3. 09:54

  4. 09:39

  5. 07:31

  6. 07:10

  7. 14:15

  8. 11:04