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. beeline GmbH, Köln
  2. Robert Bosch GmbH, Stuttgart-Feuerbach
  3. über Hanseatisches Personalkontor Berlin, Berlin
  4. Robert Bosch GmbH, Reutlingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 69,99€ (Release 31.03.)
  2. 6,49€
  3. 69,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Begnadigung: Danke, Chelsea Manning!
Begnadigung
Danke, Chelsea Manning!
  1. Verwirrung Assange will nicht in die USA - oder doch?
  2. Nach Begnadigung Mannings Assange weiter zu Auslieferung in die USA bereit
  3. Whistleblowerin Obama begnadigt Chelsea Manning

Shield TV (2017) im Test: Nvidias sonderbare Neuauflage
Shield TV (2017) im Test
Nvidias sonderbare Neuauflage
  1. Wayland Google erstellt Gamepad-Support für Android in Chrome OS
  2. Android Nougat Nvidia bringt Experience Upgrade 5.0 für Shield TV
  3. Nvidia Das Shield TV wird kleiner und kommt mit mehr Zubehör

Nintendo Switch im Hands on: Die Rückkehr der Fuchtel-Ritter
Nintendo Switch im Hands on
Die Rückkehr der Fuchtel-Ritter
  1. Nintendo Vorerst keine Videostreaming-Apps auf Switch
  2. Arms angespielt Besser boxen ohne echte Arme
  3. Nintendo Switch Eltern bekommen totale Kontrolle per App

  1. Funkchips: Apple klagt gegen Qualcomm
    Funkchips
    Apple klagt gegen Qualcomm

    Rund eine Milliarde US-Dollar will Apple von Qualcomm haben. Der Chiphersteller ärgert sich aber über Apple und hält das Geld zurück. Deshalb klagt Apple.

  2. Die Woche im Video: B/ow the Wh:st/e!
    Die Woche im Video
    B/ow the Wh:st/e!

    Golem.de-Wochenrückblick Ein Whistleblower begnadigt, einer länger im Exil - und ein Australier, der Aufmerksamkeit sucht. Dazu fröhliche Konsolenspieler mit neuem Nintendo-Spielzeug und aus Mozilla wird Moz://a. Sieben Tage und viele Meldungen im Überblick.

  3. Verbraucherzentrale: O2-Datenautomatik dürfte vor Bundesgerichtshof gehen
    Verbraucherzentrale
    O2-Datenautomatik dürfte vor Bundesgerichtshof gehen

    Ob die Datenautomatik von O2 auch vor dem Bundesgerichtshof besteht, könnte bald entschieden werden. Das Oberlandesgericht München soll die Revision ausdrücklich zugelassen haben.


  1. 11:21

  2. 09:02

  3. 19:03

  4. 18:45

  5. 18:27

  6. 18:12

  7. 17:57

  8. 17:41