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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

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

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

    +1

    Benutzer wird von Ihnen ignoriert. Anzeigen

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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

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

    Benutzer wird von Ihnen ignoriert. Anzeigen

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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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 :)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Security: Smarthomes, offen wie Scheunentore
Security
Smarthomes, offen wie Scheunentore
  1. Software-Plattform Bosch und Cisco gründen Joint Venture für Smart Home
  2. Pantelligent Die funkende Bratpfanne
  3. Smarthome Das intelligente Haus wird nie fertig

Jahresrückblick: Was 2014 bei Golem.de los war
Jahresrückblick
Was 2014 bei Golem.de los war
  1. In eigener Sache Golem.de sucht (Junior) Concepter/-in für Onlinewerbung
  2. In eigener Sache Golem.de offline und unplugged
  3. In eigener Sache Golem.de sucht Videoredakteur/-in

E-Mail-Ausfall in München: Und wieder wars nicht Limux
E-Mail-Ausfall in München
Und wieder wars nicht Limux
  1. Öffentliche Verwaltung Massiver E-Mail-Ausfall bei der Stadt München
  2. Limux Kopf einziehen und über Verschwörung tuscheln
  3. Limux Windows-Rückkehr würde München Millionen kosten

  1. Story Mode: Telltale arbeiten an Minecraft-Episodenabenteuer
    Story Mode
    Telltale arbeiten an Minecraft-Episodenabenteuer

    Keine Klötzchen, sondern eine Handlung steht im Mittelpunkt von Minecraft: Story Mode. Das Adventure entsteht bei Telltale und Mojang - und auch die Community soll beteiligt werden.

  2. Deutscher Entwicklerpreis 2014: Lords of the Fallen schafft eines von drei Triples
    Deutscher Entwicklerpreis 2014
    Lords of the Fallen schafft eines von drei Triples

    Der Actiontitel Lords of the Fallen galt im Vorfeld als Favorit beim Deutschen Entwicklerpreis 2014. Bei der Preisverleihung in Köln konnte er dann drei Awards gewinnen - genauso wie auch zwei andere Spiele.

  3. General vor dem NSA-Ausschuss: Der Feuerwehrmann des BND
    General vor dem NSA-Ausschuss
    Der Feuerwehrmann des BND

    Er war die treibende Kraft hinter der Operation Eikonal: Um dem BND zeitgemäßes Know-how und Technik zu besorgen, bot ein Abteilungsleiter der NSA den Zugriff auf den Frankfurter Internetknoten an. Mit einigen Tricks.


  1. 23:19

  2. 22:31

  3. 19:22

  4. 16:44

  5. 16:34

  6. 15:41

  7. 15:34

  8. 15:22