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. Robert Bosch GmbH, Abstatt
  2. über Ratbacher GmbH, München
  3. Rems-Murr-Kliniken gGmbH, Winnenden
  4. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 15€ sparen mit Gutscheincode GTX15 (Bestpreis laut Preisvergleich)
  2. (u. a. 3x B12-PS 120mm für 49,90€, 3x B14-1 140mm für 63,90€ statt 71,70€)
  3. Boomster 279,99€, Consono 35 MK3 5.1-Set 333,00€, Move BT 119,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Google, Apple und Mailaccounts: Zwei-Faktor-Authentifizierung richtig nutzen
Google, Apple und Mailaccounts
Zwei-Faktor-Authentifizierung richtig nutzen
  1. Bugs in Encase Mit dem Forensik-Tool die Polizei hacken
  2. Red Star OS Sicherheitslücke in Nordkoreas Staats-Linux
  3. 0-Day Tor und Firefox patchen ausgenutzten Javascript-Exploit

Steep im Test: Frei und einsam beim Bergsport
Steep im Test
Frei und einsam beim Bergsport
  1. PES 2017 Update mit Stadion und Hymnen von Borussia Dortmund
  2. Motorsport Manager im Kurztest Neustart für Sportmanager
  3. NBA 2K17 10.000 Schritte für Ingame-Boost

Kosmobits im Test: Tausch den Spielecontroller gegen einen Mikrocontroller!
Kosmobits im Test
Tausch den Spielecontroller gegen einen Mikrocontroller!
  1. HiFive 1 Entwicklerboard mit freiem RISC-Prozessor verfügbar
  2. Simatic IoT2020 Siemens stellt linuxfähigen Arduino-Klon vor
  3. Calliope Mini Mikrocontroller-Board für deutsche Schüler angekündigt

  1. Projekt Titan: Apple will Anti-Kollisionssystem für Autos patentieren
    Projekt Titan
    Apple will Anti-Kollisionssystem für Autos patentieren

    Sensoren sollen künftig erkennen, ob Autos und andere Hindernisse vor ihnen in Bewegung sind oder stehen, um Kollisionen zu vermeiden. Ein solches System will Apple patentieren und zeigt damit zum zweiten Mal öffentlich Interesse an Autothemen, die dem Unternehmen seit langem nachgesagt werden.

  2. Visualisierungsprogramm: Microsoft bringt Visio für iOS
    Visualisierungsprogramm
    Microsoft bringt Visio für iOS

    Microsoft hat sein Visualisierungsprogramm Viso auf die iOS-Plattform portiert. Zunächst erscheint der Visio Viewer nur für das iPad, später soll eine iPhone-Version folgen.

  3. Auftragsfertiger: TSMC investiert 16 Milliarden US-Dollar in neue Fab
    Auftragsfertiger
    TSMC investiert 16 Milliarden US-Dollar in neue Fab

    Für kommende Fertigungsverfahren: Die TSMC will in Taiwan ein neues Halbleiterwerk für die 5-nm- und 3-nm-Fertigung bauen. Die ersten Chips sollen frühestens 2022 vom Band laufen.


  1. 08:48

  2. 08:00

  3. 07:43

  4. 07:28

  5. 07:15

  6. 18:02

  7. 16:46

  8. 16:39