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...

Anzeige
  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

Anzeige
Stellenmarkt
  1. Laube Automobile GmbH, Weischlitz
  2. GRENZEBACH Maschinenbau GmbH, Asbach-Bäumenheim / Hamlar
  3. Haufe Akademie GmbH & Co. KG, Freiburg im Breisgau
  4. MBtech Group GmbH & Co. KGaA, Regensburg / Neutraubling

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 49,97€
  2. 110,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


­Cybersyn: Chiles Traum von der computergesteuerten Planwirtschaft
­Cybersyn
Chiles Traum von der computergesteuerten Planwirtschaft
  1. Linux Kernel-Sicherheitsinitiative wächst "langsam aber stetig"
  2. Power9 IBMs 24-Kern-Chip kann 8 TByte RAM pro Sockel nutzen
  3. Adecco IBM will Helpdesk-Geschäft in Erfurt und Leipzig loswerden

Thinkpad X1 Carbon 2013 vs 2016: Drei Jahre, zwei Ultrabooks, eine Erkenntnis
Thinkpad X1 Carbon 2013 vs 2016
Drei Jahre, zwei Ultrabooks, eine Erkenntnis
  1. Huawei Matebook im Test Guter Laptop-Ersatz mit zu starker Konkurrenz
  2. iPad Pro Case Razer zeigt flache mechanische Switches
  3. Thinkpwn Lenovo warnt vor mysteriöser Bios-Schwachstelle

Asus PG248Q im Test: 180 Hertz erkannt, 180 Hertz gebannt
Asus PG248Q im Test
180 Hertz erkannt, 180 Hertz gebannt
  1. Raspberry Pi 3 Booten über USB oder per Ethernet
  2. Autonomes Fahren Mercedes stoppt Werbespot wegen überzogener Versprechen
  3. Radeon RX 480 Dank DX12 und Vulkan reicht auch eine Mittelklasse-CPU

  1. Autonomes Fahren: Suchmaschinenkonzern Yandex baut fahrerlosen Bus
    Autonomes Fahren
    Suchmaschinenkonzern Yandex baut fahrerlosen Bus

    Noch ein Suchmaschinenbetreiber, der sich mit autonomem Fahren beschäftigt: Das russische Unternehmen Yandex entwickelt zusammen mit mehreren Partnern einen fahrerlosen Bus. Bei dem Projekt ist auch ein deutscher Konzern dabei.

  2. No Man's Sky: Steam wehrt sich gegen Erstattungen
    No Man's Sky
    Steam wehrt sich gegen Erstattungen

    In Foren machen Berichte die Runde, wonach auch nach vielen Spielstunden eine Rückgabe von No Man's Sky auf Steam möglich sei. Nun macht Valve deutlich, dass die regulären Erstattungsrichtlinien gelten.

  3. Electronic Arts: Battlefield 1 setzt Gold, aber nicht Plus voraus
    Electronic Arts
    Battlefield 1 setzt Gold, aber nicht Plus voraus

    Derzeit startet die offene Beta von Battlefield 1 - mit unterschiedlichen Bedingungen für Nutzer der Playstation 4 und Xbox Live: Nur auf einem der beiden Systeme ist keine kostenpflichtige Mitgliedschaft nötig.


  1. 17:39

  2. 17:19

  3. 15:32

  4. 15:01

  5. 14:57

  6. 14:24

  7. 14:00

  8. 12:59